diff --git a/Makefile b/Makefile index e0bb8d49..ce5cdbc7 100644 --- a/Makefile +++ b/Makefile @@ -2,9 +2,12 @@ .PHONY: all all-zips tag-release protocol discard all-zips: .Makefile.uptodate - find . -name 'zip-*.rst' -o -name 'zip-*.md' |sort >.zipfilelist.new + echo "$(sort $(wildcard zip-*.rst) $(wildcard zip-*.md))" >.zipfilelist.new diff .zipfilelist.current .zipfilelist.new || cp -f .zipfilelist.new .zipfilelist.current rm -f .zipfilelist.new + echo "$(sort $(wildcard draft-*.rst) $(wildcard draft-*.md))" >.draftfilelist.new + diff .draftfilelist.current .draftfilelist.new || cp -f .draftfilelist.new .draftfilelist.current + rm -f .draftfilelist.new $(MAKE) README.rst $(MAKE) index.html $(addsuffix .html,$(filter-out README,$(basename $(sort $(wildcard *.rst) $(wildcard *.md))))) @@ -19,7 +22,7 @@ protocol: discard: git checkout -- '*.html' 'README.rst' 'protocol/*.pdf' -.Makefile.uptodate: Makefile +.Makefile.uptodate: Makefile edithtml.sh $(MAKE) clean touch .Makefile.uptodate @@ -44,7 +47,7 @@ index.html: README.rst edithtml.sh %.html: %.md edithtml.sh $(PROCESSMD) -README.rst: .zipfilelist.current makeindex.sh README.template $(sort $(wildcard zip-*.rst) $(wildcard zip-*.md)) +README.rst: .zipfilelist.current .draftfilelist.current makeindex.sh README.template $(wildcard zip-*.rst) $(wildcard zip-*.md) $(wildcard draft-*.rst) $(wildcard draft-*.md) ./makeindex.sh | cat README.template - >README.rst .PHONY: linkcheck diff --git a/README.rst b/README.rst index 747373bb..5fc4ea56 100644 --- a/README.rst +++ b/README.rst @@ -39,26 +39,6 @@ Use ``make`` to check that you are using correct and double-check the generated ``draft-*.html`` file before filing a Pull Request. See `here `__ for the project dependencies. -NU5 ZIPs --------- - -This is the list of ZIPs relevant to the NU5 Upgrade, which `activated on 31st May 2022 `__: - -- `ZIP 32: Shielded Hierarchical Deterministic Wallets `__ (updated) -- `ZIP 203: Transaction Expiry `__ (updated) -- `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances `__ (updated) -- `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext `__ (updated) -- `ZIP 213: Shielded Coinbase `__ (updated) -- `ZIP 216: Require Canonical Jubjub Point Encodings `__ -- `ZIP 221: FlyClient - Consensus-Layer Changes `__ (updated) -- `ZIP 224: Orchard Shielded Protocol `__ -- `ZIP 225: Version 5 Transaction Format `__ -- `ZIP 239: Relay of Version 5 Transactions `__ -- `ZIP 244: Transaction Identifier Non-Malleability `__ -- `ZIP 252: Deployment of the NU5 Network Upgrade `__ -- `ZIP 316: Unified Addresses and Unified Viewing Keys `__ -- `ZIP 401: Addressing Mempool Denial-of-Service `__ (clarified) - License ------- @@ -119,6 +99,7 @@ Index of ZIPs 250 Deployment of the Heartwood Network Upgrade Final 251 Deployment of the Canopy Network Upgrade Final 252 Deployment of the NU5 Network Upgrade Final + 253 Deployment of the NU6 Network Upgrade Reserved 300 Cross-chain Atomic Transactions Proposed 301 Zcash Stratum Protocol Final 302 Standardized Memo Field Format Draft @@ -139,10 +120,11 @@ Index of ZIPs 317 Proportional Transfer Fee Mechanism Active 318 Associated Payload Encryption Reserved 319 Options for Shielded Pool Retirement Reserved - 320 Defining an Address Type to which funds can only be sent from Transparent Addresses Draft + 320 Defining an Address Type to which funds can only be sent from Transparent Addresses Proposed 321 Payment Request URIs Proposed 322 Generic Signed Message Format Reserved 323 Specification of getblocktemplate for Zcash Reserved + 324 URI-Encapsulated Payments Draft 332 Wallet Recovery from zcashd HD Seeds Reserved 339 Wallet Recovery Words Reserved 400 Wallet.dat format Draft @@ -164,5 +146,6 @@ Index of ZIPs 1012 Dev Fund to ECC + ZF + Major Grants Obsolete 1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active + guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft diff --git a/css/style.css b/css/style.css index 1eee84aa..77af4d69 100644 --- a/css/style.css +++ b/css/style.css @@ -18,6 +18,9 @@ #index-of-zips table tr:hover { background-color: #eff1f2; } + #drafts-without-assigned-zip-numbers table tr:hover { + background-color: #eff1f2; + } aside.note { background-color: #a0a0ff; color: #111519; @@ -72,6 +75,9 @@ #index-of-zips table tr:hover { background-color: #303030; } + #drafts-without-assigned-zip-numbers table tr:hover { + background-color: #303030; + } aside.note { background-color: #6060e0; color: #ffffff; @@ -370,6 +376,10 @@ td:first-child { text-align: center; } +#drafts-without-assigned-zip-numbers table td:first-child { + text-align: left; +} + #index-of-zips table td:first-child + td { padding: 0; } diff --git a/index.html b/index.html index 6f05b1fe..0e93d84b 100644 --- a/index.html +++ b/index.html @@ -24,25 +24,6 @@

To start contributing, first read ZIP 0 which documents the ZIP process. Then clone this repo from GitHub, and start adding your draft ZIP, formatted either as reStructuredText or as Markdown.

For example, if using reStructuredText, use a filename matching draft-*.rst. Use make to check that you are using correct reStructuredText or Markdown syntax, and double-check the generated draft-*.html file before filing a Pull Request. See here for the project dependencies.

-

NU5 ZIPs

-

This is the list of ZIPs relevant to the NU5 Upgrade, which activated on 31st May 2022:

- -

License

Unless otherwise stated in this repository’s individual files, the contents of this repository are released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT .

@@ -93,6 +74,7 @@ 250 Deployment of the Heartwood Network Upgrade Final 251 Deployment of the Canopy Network Upgrade Final 252 Deployment of the NU5 Network Upgrade Final + 253 Deployment of the NU6 Network Upgrade Reserved 300 Cross-chain Atomic Transactions Proposed 301 Zcash Stratum Protocol Final 302 Standardized Memo Field Format Draft @@ -113,10 +95,11 @@ 317 Proportional Transfer Fee Mechanism Active 318 Associated Payload Encryption Reserved 319 Options for Shielded Pool Retirement Reserved - 320 Defining an Address Type to which funds can only be sent from Transparent Addresses Draft + 320 Defining an Address Type to which funds can only be sent from Transparent Addresses Proposed 321 Payment Request URIs Proposed 322 Generic Signed Message Format Reserved 323 Specification of getblocktemplate for Zcash Reserved + 324 URI-Encapsulated Payments Draft 332 Wallet Recovery from zcashd HD Seeds Reserved 339 Wallet Recovery Words Reserved 400 Wallet.dat format Draft @@ -138,6 +121,7 @@ 1012 Dev Fund to ECC + ZF + Major Grants Obsolete 1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active + guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft diff --git a/makeindex.sh b/makeindex.sh index 2b59a4fa..b7034c2f 100755 --- a/makeindex.sh +++ b/makeindex.sh @@ -20,8 +20,11 @@ for zipfile in $(cat .zipfilelist.current); do echo " `basename $(basename $zipfile .rst) .md | sed -E 's@zip-0{0,3}@@'` `grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'` `grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`" fi done -cat < +echo " " + +if [ $(wc -c <.draftfilelist.current) -gt 1 ] +then + cat < -EndOfBlock -for draftfile in $(find . -name 'draft-*.rst' -o -name 'draft-*.md' | sort); do - echo Adding $draftfile to index. >/dev/stderr - echo " " -done -echo "
Title
`grep '^\s*Title:' $draftfile | sed -E 's@\s*Title:\s*@@'`
" +EndOfDraftHeader + for draftfile in $(cat .draftfilelist.current); do + echo Adding $draftfile to index of drafts. >/dev/stderr + echo " `grep '^\s*Title:' $draftfile | sed -E 's@\s*Title:\s*@@'`" + done + echo " " +fi diff --git a/protocol/blossom.pdf b/protocol/blossom.pdf index 2b34f68b..6ebbbe54 100644 Binary files a/protocol/blossom.pdf and b/protocol/blossom.pdf differ diff --git a/protocol/canopy.pdf b/protocol/canopy.pdf index 763e9212..bd1cb889 100644 Binary files a/protocol/canopy.pdf and b/protocol/canopy.pdf differ diff --git a/protocol/heartwood.pdf b/protocol/heartwood.pdf index c2534286..ba7423ba 100644 Binary files a/protocol/heartwood.pdf and b/protocol/heartwood.pdf differ diff --git a/protocol/nu5.pdf b/protocol/nu5.pdf index b9b2c0f4..6091c70e 100644 Binary files a/protocol/nu5.pdf and b/protocol/nu5.pdf differ diff --git a/protocol/protocol.pdf b/protocol/protocol.pdf index b9b2c0f4..6091c70e 100644 Binary files a/protocol/protocol.pdf and b/protocol/protocol.pdf differ diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 8beb8288..53f3a283 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -38,7 +38,7 @@ \usepackage[nobottomtitles,explicit]{titlesec} \usepackage[hang]{footmisc} \usepackage{xstring} -\usepackage[usenames,dvipsnames]{xcolor} +\usepackage[dvipsnames]{xcolor} \usepackage{etoolbox} \usepackage{subdepth} \usepackage{fix-cm} @@ -59,6 +59,14 @@ % \newcommand{\increment}[1]{\the\numexpr #1+1\relax} +% Shortcut for \nohyphens from hyphenat. +\newcommand{\nh}[1]{\nohyphens{#1}} + +% \nh doesn't work in the bibliography. +% +\makeatletter +\newcommand*\nbh{\hbox{-}\nobreak\hskip\z@skip} +\makeatother % The destlabel option creates "destination names" in the PDF, which allows % linking to sections in URL fragments when viewing the PDF in a web browser: @@ -335,7 +343,7 @@ \newcommand{\addparttocontents}[1]{\phantomsection\addcontentsline{toc}{section}{\larger{#1}}} \newcommand{\phantompart}[2]{\def\sectionlabel{#2} \addparttocontents{#1}\label{#2}} -\newcommand{\lpart}[2]{\def\sectionlabel{#2} \intropart\vspace{20ex}\addparttocontents{#1}\section*{#1}\label{#2}} +\newcommand{\lpart}[2]{\def\sectionlabel{#2} \intropart\vspace{20ex}\addparttocontents{#1}\section*{\nh{#1}}\label{#2}} \newcommand{\lsection}[2]{\def\sectionlabel{#2} \section{#1}\label{#2}} \newcommand{\lsubsection}[2]{\def\sectionlabel{#2} \subsection{#1}\label{#2}} \newcommand{\lsubsubsection}[2]{\def\sectionlabel{#2} \subsubsection{#1}\label{#2}} @@ -557,7 +565,7 @@ \InputIfFileExists{protocol.ver}{}{} \newcommand{\doctitle}{Zcash Protocol Specification} -\newcommand{\leadauthor}{Daira Emma Hopwood} +\newcommand{\leadauthor}{Daira-Emma Hopwood} \newcommand{\coauthora}{Sean Bowe} \newcommand{\coauthorb}{Taylor Hornby} \newcommand{\coauthorc}{Nathan Wilcox} @@ -692,7 +700,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\consensuslink}[1]{\fcolorbox{black}{\labelcolor}{% \normalfont\normalsize\noborders{\href{\codesearchurl{#1}}{\color{black}\raisebox{0.2ex}{\linkstrut}\smash{{\small \search}\, #1}}}}\,} -\newcommand{\rawterm}[1]{\textsl{#1}\kern 0.05em} +\newcommand{\rawterm}[1]{\textsl{\nh{#1}}\kern 0.05em} \newcommand{\termnoindex}[1]{\rawterm{#1}\xspace} \newcommand{\termandindex}[2]{\indexlink{\rawterm{#1}}{#2}{#2}} \newcommand{\termandindexx}[2]{\indexlink{#1}{#2}{#1}} @@ -756,25 +764,58 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\OPTIONAL}{\conformance{OPTIONAL}} \newcommand{\ALLCAPS}{\conformance{ALL CAPS}} -\newcommand{\collisionResistant}{\termandindex{collision\hyp resistant}{collision resistance}} +\newcommand{\collisionResistant}{\termandindex{collision-resistant}{collision resistance}} \newcommand{\collisionResistance}{\term{collision resistance}} \newcommand{\xCollisionResistance}{\termx{collision resistance}} \newcommand{\binding}{\termandindex{binding}{binding (commitment scheme)}} \newcommand{\hiding}{\termandindex{hiding}{hiding (commitment scheme)}} \newcommand{\quotedBinding}{\quotedtermandindex{binding}{binding (commitment scheme)}} \newcommand{\quotedHiding}{\quotedtermandindex{hiding}{hiding (commitment scheme)}} +\newcommand{\reRandomized}{\term{re-randomized}} +\newcommand{\xReRandomized}{\termx{re-randomized}} +\newcommand{\reRandomizable}{\termandindex{re-randomizable}{re-randomized}} +\newcommand{\reRandomization}{\termandindex{re-randomization}{re-randomized}} \newcommand{\randomOracle}{\term{random oracle}} \newcommand{\randomOracles}{\terms{random oracle}} \newcommand{\randomOracleAdjective}{\termandindex{random-oracle}{random oracle}} -\newcommand{\nonCanonicalPoint}{\termandindex{non\hyp canonical}{non-canonical (compressed encoding of a point)}} -\newcommand{\nonCanonicalFieldElement}{\termandindex{non\hyp canonical}{non-canonical (encoding of a field element)}} -\newcommand{\nonCanonicallyFieldElement}{\termandindex{non\hyp canonically}{non-canonical (encoding of a field element)}} +\newcommand{\nonCanonicalPoint}{\termandindex{non-canonical}{non-canonical (compressed encoding of a point)}} +\newcommand{\nonCanonicalFieldElement}{\termandindex{non-canonical}{non-canonical (encoding of a field element)}} +\newcommand{\nonCanonicallyFieldElement}{\termandindex{non-canonically}{non-canonical (encoding of a field element)}} +\newcommand{\smallOrder}{\termandindex{small order}{small order (of a group element)}} +\newcommand{\smallOrderAdjective}{\termandindex{small-order}{small order (of a group element)}} +\newcommand{\primeOrder}{\termandindex{prime order}{prime order (of a group element)}} +\newcommand{\primeOrderAdjective}{\termandindex{prime-order}{prime order (of a group element)}} +\newcommand{\primeOrderGroup}{\term{prime-order group}} +\newcommand{\primeOrderSubgroup}{\term{prime-order subgroup}} +\newcommand{\primeOrderCurve}{\term{prime-order curve}} +\newcommand{\primeOrderCurves}{\terms{prime-order curve}} +\newcommand{\hashToCurve}{\term{hash-to-curve}} \newcommand{\xDiscreteLogarithmProblem}{\term{Discrete Logarithm Problem}} \newcommand{\xDiscreteLogarithm}{\termandindex{Discrete Logarithm}{Discrete Logarithm Problem}} \newcommand{\xDecisionalDiffieHellmanProblem}{\term{Decisional Diffie--Hellman Problem}} \newcommand{\xDecisionalDiffieHellman}{\termandindex{Decisional Diffie--Hellman}{Decisional Diffie--Hellman Problem}} \newcommand{\partitioningOracleAttack}{\term{partitioning oracle attack}} \newcommand{\partitioningOracleAttacks}{\terms{partitioning oracle attack}} +\newcommand{\sideChannel}{\term{side-channel}} +\newcommand{\multiPartyComputation}{\term{multi-party computation}} + +\newcommand{\doubleSpend}{\term{double-spend}} +\newcommand{\doubleSpends}{\terms{double-spend}} +\newcommand{\doubleSpending}{\termandindex{double-spending}{double-spend}} +\newcommand{\proofOfWork}{\term{proof-of-work}} +\newcommand{\peerToPeerProtocol}{\term{peer-to-peer protocol}} +\newcommand{\peerToPeerNetwork}{\termandindex{peer-to-peer network}{peer-to-peer protocol}} +\newcommand{\inBand}{\term{in-band}} +\newcommand{\outOfBand}{\term{out-of-band}} +\newcommand{\xUSASCII}{\term{US-ASCII}} +\newcommand{\bitSequence}{\term{bit sequence}} +\newcommand{\bitSequences}{\terms{bit sequence}} +\newcommand{\bitSequenceAdjective}{\termandindex{bit-sequence}{bit sequence}} +\newcommand{\byteSequence}{\term{byte sequence}} +\newcommand{\byteSequences}{\terms{byte sequence}} +\newcommand{\byteSequenceAdjective}{\termandindex{byte-sequence}{byte sequence}} +\newcommand{\littleEndian}{\term{little-endian}} +\newcommand{\bigEndian}{\term{big-endian}} \newcommand{\shaHash}{\termandindexx{$\SHAFull$}{SHA-256}} \newcommand{\shadHash}{\termandindexx{$\SHAFulld$}{SHA-256d}} @@ -791,8 +832,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\privateKeys}{\terms{private key}} \newcommand{\keyPrivacy}{\term{key privacy}} \newcommand{\xKeyPrivacy}{\termx{key privacy}} -\newcommand{\keyPrivate}{\termandindex{key\hyp private}{key privacy}} -\newcommand{\xKeyPrivate}{\termandindex{Key\hyp private}{key privacy}} +\newcommand{\keyPrivate}{\termandindex{key-private}{key privacy}} +\newcommand{\xKeyPrivate}{\termandindex{Key-private}{key privacy}} \newcommand{\ephemeralPublicKey}{\term{ephemeral public key}} \newcommand{\ephemeralPrivateKey}{\term{ephemeral private key}} @@ -896,6 +937,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\provingSystem}{\termandindex{proving system}{proving system (preprocessing zk-SNARK)}} \newcommand{\provingSystems}{\termandindex{proving systems}{proving system (preprocessing zk-SNARK)}} \newcommand{\zeroKnowledgeProvingSystem}{\termandindex{zero-knowledge proving system}{proving system (preprocessing zk-SNARK)}} +\newcommand{\zeroKnowledgeProvingSystems}{\termandindex{zero-knowledge proving systems}{proving system (preprocessing zk-SNARK)}} +\newcommand{\zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge}{\termandindex{zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs)}{proving system (preprocessing zk-SNARK)}} \newcommand{\quadraticConstraintProgram}{\term{quadratic constraint program}} \newcommand{\quadraticConstraintPrograms}{\terms{quadratic constraint program}} \newcommand{\quadraticArithmeticProgram}{\term{Quadratic Arithmetic Program}} @@ -1169,11 +1212,13 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\merkleIndices}{\termandindex{indices}{index (of a Merkle tree node)}} \newcommand{\zkSNARK}{\termandindex{zk-SNARK}{proving system (preprocessing zk-SNARK)}} \newcommand{\zkSNARKs}{\termandindex{zk-SNARKs}{proving system (preprocessing zk-SNARK)}} -\newcommand{\zkProof}{\termandindex{zk proof}{zk-SNARK proof}} -\newcommand{\zkSNARKProof}{\term{zk-SNARK proof}} -\newcommand{\zkSNARKProofs}{\terms{zk-SNARK proof}} -\newcommand{\zkSNARKCircuit}{\term{zk-SNARK circuit}} -\newcommand{\zkSNARKCircuits}{\terms{zk-SNARK circuit}} +\newcommand{\zkProof}{\termandindex{zk~proof}{zk-SNARK proof}} +\newcommand{\zeroKnowledgeProof}{\termandindex{zero-knowledge proof}{zk-SNARK proof}} +\newcommand{\zeroKnowledgeProofs}{\termandindex{zero-knowledge proofs}{zk-SNARK proof}} +\newcommand{\zkSNARKProof}{\termandindex{zk-SNARK proof}{zk-SNARK proof}} +\newcommand{\zkSNARKProofs}{\termandindex{zk-SNARK proofs}{zk-SNARK proof}} +\newcommand{\zkSNARKCircuit}{\termandindex{zk-SNARK circuit}{zk-SNARK circuit}} +\newcommand{\zkSNARKCircuits}{\termandindex{zk-SNARK circuits}{zk-SNARK circuit}} \newcommand{\libsnark}{\termandindex{libsnark}{libsnark (Zcash fork)}} \newcommand{\bellman}{\term{bellman}} \newcommand{\memo}{\term{memo field}} @@ -1190,7 +1235,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\signatureScheme}{\term{signature scheme}} \newcommand{\signatureSchemes}{\terms{signature scheme}} \newcommand{\oneTimeSignatureScheme}{\termandindex{one-time signature scheme}{one-time (signature scheme)}} -\newcommand{\rerandomizableSignatureScheme}{\termandindex{signature scheme with re\hyp randomizable keys}{signature scheme with re-randomizable keys}} +\newcommand{\rerandomizableSignatureScheme}{\termandindex{signature scheme with re-randomizable keys}{signature scheme with re-randomizable keys}} \newcommand{\keyMonomorphicSignatureScheme}{\term{signature scheme with key monomorphism}} \newcommand{\monomorphism}{\term{monomorphism}} \newcommand{\sigNonmalleable}{\termandindex{nonmalleable}{nonmalleability (of signatures)}} @@ -2484,7 +2529,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \begin{center} \hspace{0.6em}\includegraphics[scale=.1]{jubjub} -\footnote{Jubjub bird image credit: Peter Newell 1902; Daira Emma Hopwood 2018.} +\footnote{Jubjub bird image credit: Peter Newell 1902; \nh{Daira-Emma} Hopwood 2018.} \end{center} \vspace{-6ex} @@ -2492,12 +2537,11 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \begin{abstract} \normalsize \noindent \textbf{Abstract.} \defining{\Zcash} is an implementation of the \term{Decentralized Anonymous Payment scheme} -\Zerocash, with security fixes and improvements to performance and -functionality. It bridges the existing transparent payment scheme used by -\Bitcoin with a \emph{shielded} payment scheme secured by zero-knowledge -succinct non-interactive arguments of knowledge (\zkSNARKs). It attempted -to address the problem of mining centralization by use of the \Equihash -memory-hard proof-of-work algorithm. +\Zerocash, with security fixes and improvements to performance and functionality. +It bridges the existing transparent payment scheme used by \Bitcoin with a \emph{shielded} +payment scheme secured by \zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge. +It attempted to address the problem of mining centralization by use of the \Equihash +memory-hard \proofOfWork algorithm. \vspace{1.5ex} \notblossom{\sapling{\noindent This specification defines the \Zcash consensus protocol @@ -2554,8 +2598,7 @@ This document was built with Lua\TeX, which is \href{https://github.com/zcash/zi \Zerocash \cite{BCGGMTV2014}}, with security fixes and improvements to performance and functionality. It bridges the existing transparent payment scheme used by \defining{\Bitcoin \cite{Nakamoto2008}} with a -\emph{shielded} payment scheme secured by zero-knowledge succinct -non-interactive arguments of knowledge (\zkSNARKs). +\emph{shielded} payment scheme secured by \zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge. \vspace{1ex} In this document, technical terms for concepts that play an important rôle in \Zcash are @@ -2600,7 +2643,7 @@ This specification is structured as follows: \begin{itemize} \item Notation — definitions of notation used throughout the document; \item Concepts — the principal abstractions needed to understand the protocol; - \item Abstract Protocol — a high-level description of the protocol in terms + \item Abstract Protocol — a \nh{high-level} description of the protocol in terms of ideal cryptographic components; \item Concrete Protocol — how the functions and encodings of the abstract protocol are instantiated; @@ -2757,7 +2800,7 @@ other proposals for private payment systems, such as CoinJoin \cite{Bitcoin-Coin or \CryptoNote \cite{vanSaberh2014}, that are based on mixing of a limited number of transactions and that therefore have smaller \noteTraceabilitySets. -The \nullifiers are necessary to prevent double-spending: each \note on the +The \nullifiers are necessary to prevent \doubleSpending: each \note on the \blockChain only has one valid \nullifier, and so attempting to spend a \note twice would reveal the \nullifier twice, which would cause the second \transaction to be rejected. @@ -2821,7 +2864,7 @@ means the type of sequences of length $\ell$ with elements in $T$. For example, $\bitseq{\ell}$ means the set of sequences of $\ell$ bits, and $\byteseq{k}$ means the set of sequences of $k$ bytes. -$\byteseqs$ means the type of byte sequences of arbitrary length. +$\byteseqs$ means the type of \byteSequences of arbitrary length. $\length(S)$ means the length of (number of elements in) $S$. @@ -2832,8 +2875,8 @@ digits means the corresponding integer converted from hexadecimal. $\zerobytes{\ell}$ means the sequence of $\ell$ zero bytes. $\ascii{...}$ means the given string represented as a -sequence of bytes in US-ASCII. For example, $\ascii{abc}$ represents the -byte sequence $\hexarray{61,62,63}$. +sequence of bytes in \xUSASCII. For example, $\ascii{abc}$ represents the +\byteSequence $\hexarray{61,62,63}$. $\zeros{\ell}$ means the sequence of $\ell$ zero bits. $\ones{\ell}$ means the sequence of $\ell$ one bits. @@ -2859,7 +2902,7 @@ inclusive, in descending order. $a \bconcat b$ means the concatenation of sequences $a$ then $b$. $\concatbits(S)$ means the sequence of bits obtained by -concatenating the elements of $S$ as bit sequences. +concatenating the elements of $S$ as \bitSequences. $\sorted(S)$ means the sequence formed by sorting the elements of $S$. @@ -2905,19 +2948,19 @@ means the remainder on dividing $a$ by $q$. (This usage does not conflict with the notation above for the unique representative of a field element.) -$a \xor b$ means the bitwise-exclusive-or of $a$ and $b$, -and $a \band b$ means the bitwise-and of $a$ and $b$. These are +$a \xor b$ means the \nh{bitwise-exclusive-or} of $a$ and $b$, +and $a \band b$ means the \nh{bitwise-and} of $a$ and $b$. These are defined on integers (which include bits and bytes), or elementwise on equal-length sequences of integers, according to context. \vspace{-0.5ex} $\!\vsum{i=1}{\rmN} a_i$ means the sum of $a_{\allN{}}$.\; $\vproduct{i=1}{\rmN} a_i$ means the product of $a_{\allN{}}$.\; -$\vxor{i=1}{\rmN} a_i$ means the bitwise exclusive-or of $a_{\allN{}}$. +$\vxor{i=1}{\rmN} a_i$ means the \nh{bitwise-exclusive-or} of $a_{\allN{}}$. When $N = 0$ these yield the appropriate neutral element, i.e. $\ssum{i=1}{0} a_i = 0$, $\sproduct{i=1}{0} a_i = 1$, and -$\sxor{i=1}{0} a_i = 0$ or the all-zero bit sequence of length given +$\sxor{i=1}{0} a_i = 0$ or the \nh{all-zero} \bitSequence of length given by the type of $a$. $\possqrt{a}$, where $a \typecolon \GF{q}$, means the positive square root @@ -2943,7 +2986,7 @@ The $\scalarmult{k}{P}$ notation for scalar multiplication in a group is defined in \crossref{abstractgroup}. The convention of affixing $\Repr$ to a variable name is used -for variables that denote bit-sequence representations of group elements. +for variables that denote \bitSequence representations of group elements. The binary relations $<$, $\leq$, $=$, $\geq$, and $>$ have their conventional meanings on integers and rationals, and are defined lexicographically on @@ -2973,7 +3016,7 @@ The following integer constants will be instantiated in \crossref{constants}: \end{formulae} The rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$;\notnufive{ and} -the bit sequence constants $\Uncommitted{Sprout} \typecolon \bitseq{\smash{\MerkleHashLength{Sprout}}}$\sapling{ and +the \bitSequenceAdjective constants $\Uncommitted{Sprout} \typecolon \bitseq{\smash{\MerkleHashLength{Sprout}}}$\sapling{ and $\Uncommitted{Sapling} \typecolon \bitseq{\smash{\MerkleHashLength{Sapling}}}$}\nufive{; and the constant $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$} will also be defined in that section. @@ -3208,7 +3251,7 @@ a representation of the \noteCommitment $\cm$ described in \crossref{notecommitm A \notePlaintext also includes a $\MemoByteLength$-byte \defining{\memo} associated with this \note. The usage of the \memo is by agreement between the sender and recipient -of the \note. \RECOMMENDED non-consensus constraints on the \memo contents are specified +of the \note. \RECOMMENDED{} \nh{non-consensus} constraints on the \memo contents are specified in \cite{ZIP-302}. For \Sprout, the \notePlaintexts in each \joinSplitDescription are encrypted to the respective @@ -3355,7 +3398,7 @@ of a \Pallas curve point, as specified in \crossref{actiondesc}. \lsubsubsection{Nullifiers}{nullifierconcept} The \nullifier for a \note, denoted $\nf$, is a value unique to the \note that is used -to prevent double-spends. When a \transaction that contains one or more +to prevent \doubleSpends. When a \transaction that contains one or more \joinSplitDescriptions\sapling{ or \spendDescriptions}\nufive{ or \actionDescriptions} is entered into the \blockChain, all of the \defining{\nullifiers} for \notes spent by that \transaction are added to the \nullifierSet of the associated \treestate. A \transaction @@ -3366,14 +3409,14 @@ in the set. in \crossref{nullifierset}. \vspace{1.5ex} -In more detail, when a \note is spent, the spender creates a zero-knowledge proof that +In more detail, when a \note is spent, the spender creates a \zeroKnowledgeProof that it knows $(\NoteUniqueRand, \AuthPrivate)$\sapling{ or $(\NoteUniqueRand, \AuthSignPublic, \AuthProvePrivate)$}\nufive{ or $(\NoteUniqueRand, \AuthSignPublic, \NullifierKey)$}, consistent with the publically disclosed \nullifier and some previously committed \noteCommitment. Because each \note can have only a single \nullifier, and the same \nullifier value -cannot appear more than once in a \validBlockChain, double-spending is prevented. +cannot appear more than once in a \validBlockChain, \doubleSpending is prevented. \vspace{1.5ex} The \nullifier for a \Sprout \note is derived from the $\NoteUniqueRand$ value and @@ -3422,7 +3465,7 @@ that it received first. The consensus protocol is designed to ensure that for any given \blockHeight, the vast majority of well-connected nodes should eventually agree on their \bestValidBlockChain up to that height. A \fullValidator\footnote{There is reason to follow the requirements -in this section also for non-full validators, but those are outside the scope of this +in this section also for \nh{non-full~validators}, but those are outside the scope of this protocol specification.} \SHOULD attempt to obtain candidate \blocks from multiple sources in order to increase the likelihood that it will find a \validBlockChain that reflects a recent consensus state. @@ -3450,7 +3493,7 @@ Each \transaction has a \defining{\transactionID}. \xTransactionIDs are used to rooted at $\hashMerkleRoot$, and in other parts of the ecosystem; for example they are shown in \blockChain explorers and can be used in higher-level protocols. \nufive{Version 5 \transactions also have a \defining{\wtxid}, which is used instead of -the \transactionID when gossiping \transactions in the peer-to-peer protocol \cite{ZIP-239}.} +the \transactionID when gossiping \transactions in the \peerToPeerProtocol \cite{ZIP-239}.} The computation of \transactionIDs\nufive{ and \wtxids} is described in \crossref{txnidentifiers}. \nufive{For more detail on the distinction between these two identifiers and when to use each of them, see \cite{ZIP-239} and \cite{ZIP-244}.} @@ -3532,7 +3575,7 @@ The \anchor of each \joinSplitDescription in a \transaction{} refers to a \Sprout \treestate. For each of the $\NOld$ \shieldedInputs, a \nullifier is revealed. This allows -detection of double-spends as described in \crossref{nullifierset}. +detection of \doubleSpends as described in \crossref{nullifierset}. For each \joinSplitDescription in a \transaction, an interstitial output \treestate is constructed which adds the \noteCommitments and \nullifiers specified in that @@ -3600,7 +3643,7 @@ This approach allows all of the \zkSNARK \statements to be independent of each other, potentially increasing opportunities for precomputation. A \spendDescription specifies an \anchor, which refers to the output \Sapling \treestate -of a previous \block. It also reveals a \nullifier, which allows detection of double-spends +of a previous \block. It also reveals a \nullifier, which allows detection of \doubleSpends as described in \crossref{nullifierconcept}. \vspace{-2ex} @@ -3689,7 +3732,7 @@ defined in \crossref{constants}. \noteCommitments that \joinSplitTransfers\sapling{ or \spendTransfers}\nufive{ or \actionTransfers} produce. Just as the \defining{\utxoSetFull} used in \Bitcoin, it is used to express the existence of value and the capability to spend it. However, unlike the \utxoSet, -it is \emph{not} the job of this tree to protect against double-spending, as it is +it is \emph{not} the job of this tree to protect against \doubleSpending, as it is append-only. A \defining{\merkleRoot} of a \noteCommitmentTree is associated with each \treestate @@ -3728,7 +3771,7 @@ each \treestate. As valid \transactions containing \joinSplitTransfers\sapling{ revealed in \joinSplitDescriptions\sapling{ and \spendDescriptions}\nufive{ and \actionDescriptions} are inserted into the \nullifierSet associated with the new \treestate. \xNullifiers are enforced to be unique within a \validBlockChain, in order to prevent -double-spends. +\doubleSpends. \consensusrule{ A \nullifier \MUSTNOT repeat either within a \transaction, or across \transactions @@ -3869,7 +3912,7 @@ rely only on the original abstraction. An abstraction can also be incomplete (not quite the same thing as being leaky): it intentionally --usually for simplicity-- does not model an aspect of behaviour that is important to security or correctness. An example -would be resistance to side-channel attacks; this specification says little about side-channel defence, among +would be resistance to \sideChannel attacks; this specification says little about \sideChannel defence, among many other implementation concerns. @@ -4087,7 +4130,7 @@ $\SymDecrypt{\Key}(\SymEncrypt{\Key}(\Ptext)) = \Ptext$. $\bot$ is used to represent the decryption of an invalid ciphertext. \securityrequirement{ -$\Sym$ must be \defining{\oneTime} (INT-CTXT $\wedge$ IND-CPA)-secure \cite{BN2007}. +$\Sym$ must be \defining{\oneTime} \nh{(INT-CTXT $\wedge$ IND-CPA)-secure} \cite{BN2007}. \quotedtermnoindex{One-time} here means that an honest protocol participant will almost surely encrypt only one message with a given key; however, the adversary may make many adaptive chosen ciphertext queries for a given key. @@ -4176,12 +4219,12 @@ with $\KA{Orchard}$ and derives keys for $\SymEncrypt{}$. \vspace{-1.5ex} \begin{securityrequirements} \item The asymmetric encryption scheme in \crossref{sproutinband}, constructed - from $\KA{Sprout}$, $\KDF{Sprout}$ and $\Sym$, is required to be IND-CCA2-secure + from $\KA{Sprout}$, $\KDF{Sprout}$ and $\Sym$, is required to be \nh{IND-CCA2-secure} and \keyPrivate. \item \sapling{ The asymmetric encryption scheme in \crossref{saplingandorchardinband}, constructed from $\KA{Sapling}$, $\KDF{Sapling}$ and $\Sym$\nufive{ or from $\KA{Orchard}$, - $\KDF{Orchard}$ and $\Sym$}, is required to be IND-CCA2-secure and \keyPrivate. + $\KDF{Orchard}$ and $\Sym$}, is required to be \nh{IND-CCA2-secure} and \keyPrivate. } %sapling \end{securityrequirements} @@ -4248,7 +4291,7 @@ in \crossref{abstractsigmono}.} \vspace{-1ex} \securityrequirement{ $\JoinSplitSig$\sapling{ and\nufive{ each instantiation of} $\BindingSig{}$} must be -Strongly Unforgeable under (non-adaptive) Chosen Message Attack (SU-CMA), as defined for example in +Strongly Unforgeable under (non-adaptive) Chosen Message Attack \nh{(SU-CMA)}, as defined for example in \cite[Definition 6]{BDEHR2011}.\footnote{The scheme defined in that paper was attacked in \cite{LM2017}, but this has no impact on the applicability of the definition.} This allows an adversary to obtain signatures on chosen messages, and then requires it to be @@ -4279,7 +4322,7 @@ pair without access to the \signingKey. in the same distribution as of freshly generated key pairs, for each \transaction containing \spendDescriptions or \outputDescriptions\nufive{ or \actionDescriptions}.} - \item SU-CMA security requires it to be infeasible for the adversary, not + \item \nh{SU-CMA} security requires it to be infeasible for the adversary, not knowing the \defining{\privateKey}, to forge a distinct signature on a previously seen message. That is, \joinSplitSignatures\sapling{ and \saplingBindingSignatures}\nufive{ and \orchardBindingSignatures} @@ -4332,13 +4375,13 @@ such that: \vspace{-1.5ex} 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 -(the latter is called ``Unforgeability under Re-randomized Keys'' in -\cite[Definition 8]{FKMSSS2016}). Unlike the case for $\JoinSplitSig$, we require +given in \cite[section 3]{FKMSSS2016}. \defining{Note that we require Strong Unforgeability +with \xReRandomized Keys, not Existential Unforgeability with \xReRandomized Keys +(the latter is called ``Unforgeability under \xReRandomized Keys'' in +\cite[Definition 8]{FKMSSS2016}).} Unlike the case for $\JoinSplitSig$, we require security under adaptive chosen message attack with multiple messages signed using -a given key. (Although each \note uses a different re-randomized key pair, the same -original key pair can be re-randomized for multiple \notes, and also it can happen +a given key. (Although each \note uses a different \reRandomized key pair, the same +original key pair can be \reRandomized for multiple \notes, and also it can happen that multiple \transactions spending the same \note are revealed to an adversary.) \introlist @@ -4373,15 +4416,15 @@ $(m', \sigma') \not\in \Oracle_{\sk}\mathsf{.}Q$. are swapped relative to \cite[section 3]{FKMSSS2016}. \vspace{-0.5ex} \item The requirement for the identity \randomizer $\SigRandomizerId$ simplifies the - definition of SURK-CMA by removing the need for two oracles (because the oracle for + definition of \nh{SURK-CMA} by removing the need for two oracles (because the oracle for original keys, called $\Oracle_1$ in \cite{FKMSSS2016}, is a special case of the oracle for randomized keys). \vspace{-0.5ex} \item Since $\SigRandomizePrivate(\SigRandomizer, \sk) : \SigRandomizer \leftarrowR \SigRandom$ has an identical distribution to $\SigGenPrivate()$, - and since $\SigDerivePublic$ is a deterministic function, the combination of a re-randomized + and since $\SigDerivePublic$ is a deterministic function, the combination of a \reRandomized \validatingKey and signature(s) under that key do not reveal the key from which it was - re-randomized. + \reRandomized. \vspace{-0.5ex} \item Since $\SigRandomizePrivate_{\SigRandomizer}$ is injective and easily invertible, knowledge of $\SigRandomizePrivate(\SigRandomizer, \sk)$ @@ -4908,7 +4951,7 @@ Let $\PRFaddr{}$ be a \pseudoRandomFunction, instantiated in \crossref{concretep Let $\KA{Sprout}$ be a \keyAgreementScheme, instantiated in \crossref{concretesproutkeyagreement}. \vspace{0.3ex} -A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a bit sequence +A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a \bitSequence uniformly at random from $\bitseq{\AuthPrivateLength}$. \introlist @@ -4966,7 +5009,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 \bitSequence uniformly at random from $\SpendingKeyType$. \vspace{-0.2ex} @@ -5143,7 +5186,7 @@ Define $\ToBase{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutpu Define $\ToScalar{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{r}}$. \introlist -A new \Orchard \spendingKey $\SpendingKey$ is generated by choosing a bit sequence +A new \Orchard \spendingKey $\SpendingKey$ is generated by choosing a \bitSequence uniformly at random from $\SpendingKeyType$. From this \spendingKey, the \authSigningKey $\AuthSignPrivate \typecolon \GFstar{\ParamP{r}}$, @@ -5383,7 +5426,7 @@ where \vspace{-1ex} \begin{consensusrules} \item Elements of a \spendDescription \MUST be valid encodings of the types given above. - \item $\cv$ and $\AuthSignRandomizedPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ + \item $\cv$ and $\AuthSignRandomizedPublic$ \MUSTNOT be of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\AuthSignRandomizedPublic}$ \MUSTNOT be $\ZeroJ$. \item The proof $\Proof{\Spend}$ \MUST be valid given a \primaryInput formed from the other fields except $\spendAuthSig$ --- @@ -5404,7 +5447,7 @@ where \item As stated in \shortcrossref{concretehomomorphiccommit}, an implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$. \vspace{-0.25ex} - \item The rule that $\cv$ and $\AuthSignRandomizedPublic$ \MUST not be small-order has the effect + \item The rule that $\cv$ and $\AuthSignRandomizedPublic$ \MUST not be \smallOrderAdjective has the effect of also preventing \nonCanonicalFieldElement encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and $\reprJ\Of{\abstJ\Of{\AuthSignRandomizedPublic}\kern0.05em} = \AuthSignRandomizedPublic$. @@ -5466,7 +5509,7 @@ where \begin{consensusrules} \item Elements of an \outputDescription \MUST be valid encodings of the types given above. \vspace{-0.3ex} - \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ + \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\EphemeralPublic}$ \MUSTNOT be $\ZeroJ$. \vspace{-0.3ex} \item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed @@ -5479,7 +5522,7 @@ where \item As stated in \shortcrossref{concretehomomorphiccommit}, an implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$. \vspace{-0.25ex} - \item The rule that $\cv$ and $\EphemeralPublic$ \MUST not be small-order has the effect + \item The rule that $\cv$ and $\EphemeralPublic$ \MUST not be \smallOrderAdjective has the effect of also preventing \nonCanonicalFieldElement encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and $\reprJ\Of{\abstJ\Of{\EphemeralPublic}\kern0.05em} = \AuthSignRandomizedPublic$. @@ -5549,9 +5592,9 @@ where the \outgoingCipherKey (which can be derived from a \fullViewingKey) to recover the recipient \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey $\EphemeralPrivate$, hence the entire \notePlaintext; - \item $\enableSpends \typecolon \bit$ is a flag that is set in order to enable non-zero-valued + \item $\enableSpends \typecolon \bit$ is a flag that is set in order to enable \nh{non-zero-valued} spends in this Action; - \item $\enableOutputs \typecolon \bit$ is a flag that is set in order to enable non-zero-valued + \item $\enableOutputs \typecolon \bit$ is a flag that is set in order to enable \nh{non-zero-valued} outputs in this Action; \vspace{-0.25ex} \item $\Proof{} \typecolon \ActionProof$ is a \zkSNARKProof with \primaryInput @@ -5661,7 +5704,7 @@ and signs it with the private \defining{\joinSplitSigningKey}: \end{formulae} \vspace{-0.5ex} -Then the encoded \transaction including $\joinSplitSig$ is submitted to the peer-to-peer network. +Then the encoded \transaction including $\joinSplitSig$ is submitted to the \peerToPeerNetwork. \canopyonwardpnote{\cite{ZIP-211} specifies that nodes and wallets \MUST disable any facilities to send to \Sprout addresses. This \SHOULD be made clear in user interfaces and API documentation.} @@ -5781,7 +5824,7 @@ performs the following steps: In order to minimize information leakage, the sender \SHOULD randomize the order of \outputDescriptions in a \transaction. Other considerations relating to information leakage from the structure of \transactions are beyond the scope of this specification. -The encoded \transaction is submitted to the peer-to-peer network. +The encoded \transaction is submitted to the \peerToPeerNetwork. } %sapling @@ -5870,7 +5913,7 @@ and use that \dummyNote's \nullifier as the $\NoteUniqueRand$ value. In order to minimize information leakage, the sender \SHOULD randomize the order of \actionDescriptions in a \transaction. Other considerations relating to information leakage from the structure of \transactions are beyond the scope of this specification. -The encoded \transaction is submitted to the peer-to-peer network. +The encoded \transaction is submitted to the \peerToPeerNetwork. \pnote{ The domain separators $[4]$ and $[5]$ used in the input to $\PRFexpand{\NoteSeedBytes}$ are @@ -6075,7 +6118,7 @@ The following discussion applies independently to the \Sprout\sapling{ and \Sapl \noteCommitmentTrees. Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash, -which is a bit sequence. +which is a \bitSequence. The \merkleLayer numbered $h$, counting from \merkleLayer $0$ at the \merkleRoot, has $2^h$ \merkleNodes with \merkleIndices $0$ to $2^h-1$ inclusive. @@ -6124,7 +6167,7 @@ $\MerkleNode{\MerkleDepth{}}{i}$ is in a tree with a given \merkleRoot $\rt{} = \sapling{ \begin{pnotes} - \item For \Sapling, Merkle \merkleHashes are specified to be encoded as bit sequences, but the + \item For \Sapling, Merkle \merkleHashes are specified to be encoded as \bitSequences, but the \merkleRoot $\rt{Sapling}$ is encoded for the \primaryInput of a \spendProof as an element of $\GF{\ParamJ{q}}$, as specified in \crossref{cctsaplingspend}. The \spendCircuit allows inputs to $\MerkleCRH{Sapling}$ at each \merkleNode to be \nonCanonicallyFieldElement encoded, @@ -6153,7 +6196,7 @@ $\MerkleNode{\MerkleDepth{}}{i}$ is in a tree with a given \merkleRoot $\rt{} = \introsection \lsubsection{SIGHASH Transaction Hashing}{sighash} -\Bitcoin and \Zcash use signatures and/or non-interactive proofs associated +\Bitcoin and \Zcash use signatures and/or \nh{non-interactive} proofs associated with \transaction inputs to authorize spending. Because these signatures or proofs could otherwise be replayed in a different \transaction, it is necessary to ``bind'' them to the \transaction for which they are intended. This is done by hashing information @@ -6384,7 +6427,7 @@ $\BindingSig{Sapling}$, $\combplus$, and $\grpplus$ are instantiated in \crossre \crossref{abstractsigmono} specifies these operations and the derived notation $\combminus$, $\scombsum{i=1}{\rmN}$, $\grpminus$, and $\sgrpsum{i=1\vphantom{p}}{\rmN}$, which in this section are to be interpreted as -operating on the prime-order subgroup of the \jubjubCurve and its scalar field. +operating on the \primeOrderSubgroup of points on the \jubjubCurve and on its scalar field. \vspace{1ex} \introlist @@ -6734,7 +6777,7 @@ The \validatingKey of the signature must be revealed in the \spendDescription so signature can be checked by validators. To ensure that the \validatingKey cannot be linked to the \shieldedPaymentAddress or \spendingKey from which the \note was spent, we use a \rerandomizableSignatureScheme. The \spendStatement\nufive{ or \actionStatement} proves that -this \validatingKey is a re-randomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ +this \validatingKey is a \reRandomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ with a \randomizer known to the signer. The \defining{\spendAuthSignature} is over the \sighashTxHash, so that it cannot be replayed in other \transactions. @@ -7036,7 +7079,7 @@ $\cvOld{} = \ValueCommit{Sapling}{\ValueCommitRandOld{}}(\vOld{})$. \snarkcondition{Small order checks}{spendnonsmall} $\DiversifiedTransmitBase$ and $\AuthSignPublic$ -are not of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$ +are not of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$ and $\scalarmult{\ParamJ{h}}{\AuthSignPublic} \neq \ZeroJ$. \snarkcondition{Nullifier integrity}{spendnullifierintegrity} @@ -7073,11 +7116,11 @@ For details of the form and encoding of \spendStatement proofs, see \crossref{gr i.e.\ $\GroupJ$. \vspace{-0.5ex} \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its - input bit sequence is a canonical encoding (in $\range{0}{\ParamJ{q}-1}$) of the integer + input \bitSequence is a canonical encoding (in $\range{0}{\ParamJ{q}-1}$) of the integer from the previous \merkleLayer. \vspace{-0.5ex} \item It is \emph{not} checked in the \spendStatement that $\AuthSignRandomizedPublic$ is not of - small order. However, this \emph{is} checked outside the \spendStatement, as specified in + \smallOrder. However, this \emph{is} checked outside the \spendStatement, as specified in \crossref{spenddesc}. \vspace{-0.5ex} \item It is \emph{not} checked that $\ValueCommitRandOld{} < \ParamJ{r}$ or that $\NoteCommitRandOld{} < \ParamJ{r}$. @@ -7140,7 +7183,7 @@ where $\DiversifiedTransmitBaseRepr = \reprJ\Of{\DiversifiedTransmitBase}$\,. $\cvNew{} = \ValueCommit{Sapling}{\ValueCommitRandNew{}}(\vNew{})$. \snarkcondition{Small order check}{outputnonsmall} -$\DiversifiedTransmitBase$ is not of small order, +$\DiversifiedTransmitBase$ is not of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$. \vspace{0.5ex} @@ -7158,7 +7201,7 @@ For details of the form and encoding of \outputStatement proofs, see \crossref{g The $\ValueCommitOutput{Sapling}$ type also represents points, i.e. $\GroupJ$. \vspace{-0.5ex} \item The validity of $\DiversifiedTransmitPublicRepr$ is \emph{not} checked in this circuit (which is the reason - why it is typed as a bit sequence rather than as a point). + why it is typed as a \bitSequence rather than as a point). \vspace{-0.5ex} \item It is \emph{not} checked that $\ValueCommitRandOld{} < \ParamJ{r}$ or that $\NoteCommitRandOld{} < \ParamJ{r}$. \end{pnotes} @@ -7293,7 +7336,7 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h range $\SignedValueDifferenceType$, which is different to the range $\SignedValueFieldType$ of $\vBalance{Orchard}$. \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its - input bit sequence is a canonical encoding (in $\MerkleHashOrchard$) of the integer + input \bitSequence is a canonical encoding (in $\MerkleHashOrchard$) of the integer from the previous \merkleLayer. \item As specified in \crossref{merklepath}, the validity check is permitted to be implemented in such a way that it can pass if any $\MerkleCRH{Orchard}$ hash on the \merklePath outputs $0$. @@ -7322,7 +7365,7 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h $\SpendAuthSigRandomizePublic{Orchard}$. In particular, the representation of $(\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand) + \NoteNullifierRand) \bmod \ParamP{q}$ that is used for the scalar multiplication in $\DeriveNullifierAlg$ \MUST be checked to be - canonical in order to avoid a potential double-spend vulnerability, and similarly for the + canonical in order to avoid a potential \doubleSpend vulnerability, and similarly for the representation of $\InViewingKey$ in $\scalarmult{\InViewingKey}{\DiversifiedTransmitBaseOld}$. \end{pnotes} @@ -7365,7 +7408,7 @@ $\NoteUniqueRand$, and $\NoteCommitRand$. A \memo (\crossref{noteptconcept}) is also transmitted. To transmit these secrets securely to a recipient -\emph{without} requiring an out-of-band communication channel, the +\emph{without} requiring an \outOfBand communication channel, the \transmissionKey $\TransmitPublic$ is used to encrypt them. The recipient's possession of the associated \incomingViewingKey $\InViewingKey$ is used to reconstruct the original \note and \memo. @@ -7427,12 +7470,12 @@ The resulting \defining{\notesCiphertextSprout} is $(\EphemeralPublic, \Transmit \introlist \pnote{ It is technically possible to replace $\TransmitCiphertext{i}$ for a given \note -with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band +with a random (and undecryptable) dummy ciphertext, relying instead on \outOfBand transmission of the \note to the recipient. In this case the ephemeral key \MUST -still be generated as a random \publicKey (rather than a random bit sequence) to ensure +still be generated as a random \publicKey (rather than a random \bitSequence) to ensure indistinguishability from other \joinSplitDescriptions. This mode of operation raises further security considerations, for example of how to validate a \Sprout{} -\note received out-of-band, which are not addressed in this document. +\note received \outOfBand, which are not addressed in this document. } \lsubsubsection{Decryption (\SproutText)}{sproutdecrypt} @@ -7514,7 +7557,7 @@ $\NoteCommitRand$\canopy{ or $\NoteSeedBytes$}. A \memo (\crossref{noteptconcept is also transmitted. To transmit these secrets securely to a recipient \emph{without} requiring -an out-of-band communication channel, the \diversifiedTransmissionKey +an \outOfBand communication channel, the \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ is used to encrypt them. The recipient's possession of the associated $\KA{Sapling}$\nufive{ or $\KA{Orchard}$} \privateKey $\InViewingKey$ is used to reconstruct the original \note and \memo. @@ -7618,12 +7661,12 @@ The resulting \defining{\noteCiphertextSapling} is $(\ephemeralKey, \TransmitCip \introlist \pnote{ It is technically possible to replace $\TransmitCiphertext{}$ for a given \note -with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band +with a random (and undecryptable) dummy ciphertext, relying instead on \outOfBand transmission of the \note to the recipient. In this case the ephemeral key \MUST -still be generated as a random \publicKey (rather than a random bit sequence) to ensure +still be generated as a random \publicKey (rather than a random \bitSequence) to ensure indistinguishability from other \outputDescriptions. This mode of operation raises further security considerations, for example of how to validate a \SaplingOrOrchard \note -received out-of-band, which are not addressed in this document. +received \outOfBand, which are not addressed in this document. } %pnote } %sapling @@ -7841,7 +7884,7 @@ from $\TransmitPlaintext{}$ \notnufive{\introlist} \vspace{-0.5ex} \item A previous version of this specification did not have the requirement for the decoded point - $\DiversifiedTransmitPublic$ of a \Sapling \note to be in the set of prime-order points + $\DiversifiedTransmitPublic$ of a \Sapling \note to be in the set of \primeOrderAdjective points \smash{$\SubgroupJstar$ (i.e.\ ``if ... $\DiversifiedTransmitPublic \not\in \SubgroupJstar$}, return $\bot$''). That did not match the implementation in \zcashd. In fact the history is a little more complicated. The current specification matches the implementation in \librustzcash as of @@ -7867,7 +7910,7 @@ from $\TransmitPlaintext{}$ After \NUFive activation, the above algorithm explicitly returns $\bot$ if $\reprP\big(\DiversifiedTransmitPublic\big) \neq \DiversifiedTransmitPublicRepr$. However, this is technically redundant with the later check that returns $\bot$ if - $\DiversifiedTransmitPublic \not\in \smash{\SubgroupJstar}$, because only small-order \jubjubCurve + $\DiversifiedTransmitPublic \not\in \smash{\SubgroupJstar}$, because only \smallOrderAdjective \jubjubCurve points have \nonCanonicalPoint encodings. This check is enforced retrospectively for consensus by current \zcashd and \zebra versions, and for wallet rescanning by current \zcashd. Versions of \zcashd prior to \cite{zcashd-6725} could however @@ -7965,8 +8008,8 @@ to obtain each \note sent to the corresponding \shieldedPaymentAddress, its \mem \vspace{-1ex} In \SaplingAndOrchard, \blockChain scanning requires only the $\NullifierKey$ and $\InViewingKey$ key components, rather than a \spendingKey as in \Sprout. -Typically, these components are derived from a \fullViewingKey as described in -\crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}. +Typically, these components are derived from a \fullViewingKey +(\crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}). \vspace{0.5ex} Let $\PRFOutputLengthNfSapling$ be as defined in \crossref{constants}. @@ -8029,7 +8072,7 @@ status (spent or unspent). \item When scanning only part of a \blockChain, it may be useful to augment the above algorithm with decryption of $\OutCiphertext$ components for each \transaction, in order to obtain information about \notes that were spent in the scanned period but received outside it. - \item The above algorithm does not detect \notes that were sent ``out-of-band'' or with incorrect + \item The above algorithm does not detect \notes that were sent ``\outOfBand'' or with incorrect \noteCiphertextsSapling. It is possible to detect whether such \notes were spent only if their \nullifiers are known. \end{nnotes} @@ -8062,14 +8105,14 @@ and integers: big-endian order. \item $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \binaryrange{\ell}$ such that $\LEBStoIPOf{\ell}{S}$ is the integer represented in little-endian order by the - bit sequence $S$ of length $\ell$. + \bitSequence $S$ of length $\ell$. \item $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ such that $\LEOStoIPOf{\ell}{S}$ is the integer represented in little-endian order by the - byte sequence $S$ of length $\ell/8$. + \byteSequence $S$ of length $\ell/8$. \notbeforenufive{ \item $\BEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ such that $\BEOStoIPOf{\ell}{S}$ is the integer represented in big-endian order by the - byte sequence $S$ of length $\ell/8$. + \byteSequence $S$ of length $\ell/8$. } %notbeforenufive \item $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$ defined as follows: pad the input on the right with $8 \mult \ceiling{\ell/8} - \ell$ zero bits @@ -8086,19 +8129,19 @@ and integers: \extralabel{boxnotation}{\lsubsection{Bit layout diagrams}{bitlayout}} We sometimes use bit layout diagrams, in which each box of the diagram represents -a sequence of bits. Diagrams are read from left-to-right, with lines read from -top-to-bottom; the breaking of boxes across lines has no significance. +a sequence of bits. Diagrams are read from left to right, with lines read from +top to bottom; the breaking of boxes across lines has no significance. The bit length $\ell$ is given explicitly in each box, except when it is obvious (e.g. for a single bit, or for the notation $\zeros{\ell}$ representing the sequence of $\ell$ zero bits, or for the output of $\LEBStoOSP{\ell}$). The entire diagram represents the sequence of \emph{bytes} formed by first -concatenating these bit sequences, and then treating each subsequence of 8 bits +concatenating these \bitSequences, and then treating each subsequence of 8 bits as a byte with the bits ordered from \emph{most significant} to \emph{least significant}. Thus the \emph{most significant} bit in each byte is toward the left of a diagram. \sapling{(This convention is used only in descriptions of the $\Sprout$ design; in the \SaplingAndOrchard additions, -bit/byte sequence conversions are always specified explicitly.)} Where bit fields +\bitSequence/\byteSequence conversions are always specified explicitly.)} Where bit fields are used, the text will clarify their position in each case. @@ -8217,11 +8260,11 @@ SHA-256 and SHA-512 are defined by \cite{NIST2015}. \end{formulae} \cite{NIST2015} strictly speaking only specifies the application of SHA-256 to -messages that are bit sequences, producing outputs (``message digests'') that -are also bit sequences. In practice, SHA-256 is universally implemented with a +messages that are \bitSequences, producing outputs (``message digests'') that +are also \bitSequences. In practice, SHA-256 is universally implemented with a byte-sequence interface for messages and outputs, such that the \emph{most significant} bit of each byte corresponds to the first bit of the -associated bit sequence. (In the NIST specification ``first'' is conflated with +associated \bitSequence. (In the NIST specification ``first'' is conflated with ``leftmost''.) \introlist @@ -8351,7 +8394,7 @@ such that $\SHACompress(x) = \zeros{256}$. \begin{pnotes} \item The $\layerInput$ argument does not affect the output. \item \shaCompress is not the same as the \shaHash function, which hashes arbitrary-length - byte sequences. + \byteSequences. \end{pnotes} \sapling{ @@ -8560,27 +8603,27 @@ the third address was derived from. return $\bot$) is modelled as a \randomOracle from \diversifiers to points of order $\ParamJ{r}$ on the \jubjubCurve. In this model, Unlinkability of $\DiversifyHash{Sapling}$ holds under the \xDecisionalDiffieHellman assumption on the - prime-order subgroup of the \jubjubCurve. + \primeOrderSubgroup of points on the \jubjubCurve. To prove this, consider the ElGamal encryption scheme \cite{ElGamal1985} - on this prime-order subgroup, restricted to encrypting plaintexts encoded + on this \primeOrderSubgroup, restricted to encrypting plaintexts encoded as the group identity $\ZeroJ$. (ElGamal was originally defined for $\GFstar{p}$ - but works in any prime-order group.) ElGamal \publicKeys then have the same form + but works in any \primeOrderGroup.) ElGamal \publicKeys then have the same form as \diversifiedPaymentAddresses. If we make the assumption above on $\GroupJHash{}$, then generating a new \diversifiedPaymentAddress from a given address $\pk$, gives the same distribution of $(\DiversifiedTransmitBase', \DiversifiedTransmitPublic')$ pairs as the distribution of ElGamal ciphertexts obtained by encrypting $\ZeroJ$ under $\pk$. \todo{check whether this is justified.} - Then, the definition of \keyPrivacy (IK-CPA as defined in \cite[Definition 1]{BBDP2001}) + Then, the definition of \keyPrivacy (\nh{IK-CPA} as defined in \cite[Definition 1]{BBDP2001}) for ElGamal corresponds to the definition of Unlinkability for $\DiversifyHash{Sapling}$. - (IK-CCA corresponds to the potentially stronger requirement that $\DiversifyHash{Sapling}$ + (\nh{IK-CCA} corresponds to the potentially stronger requirement that $\DiversifyHash{Sapling}$ remains Unlinkable when given Diffie--Hellman key agreement oracles for each of the candidate \diversifiedPaymentAddresses.) So if ElGamal is \keyPrivate, then $\DiversifyHash{Sapling}$ is Unlinkable under the same conditions. \cite[Appendix A]{BBDP2001} gives a security proof for \keyPrivacy - (both IK-CPA and IK-CCA) of ElGamal under the \xDecisionalDiffieHellman + (both \nh{IK-CPA} and \nh{IK-CCA}) of ElGamal under the \xDecisionalDiffieHellman assumption on the relevant group. (In fact the proof needed is the ``small modification'' described in the last paragraph in which the generator is chosen at random for each key.) @@ -8643,7 +8686,7 @@ Jurgen Bos, George Purdy, Eugène van Heijst and Birgit Pfitzmann in \cite{CDvdG1987}, \cite{BCP1988} and \cite{CvHP1991}, and of Mihir Bellare, Oded Goldreich, and Shafi Goldwasser in \cite{BGG1995}, with optimizations for efficient instantiation in \zkSNARKCircuits -by Sean Bowe and Daira Emma Hopwood. +by Sean Bowe and \nh{Daira-Emma} Hopwood. $\PedersenHash$ is used in the definitions of \xPedersenCommitments (\crossref{concretewindowedcommit}), and of the \defining{\xPedersenHash} for the @@ -8814,7 +8857,7 @@ See \crossref{cctmixinghash} for efficient circuit implementation of this functi \vspace{-2ex} \defining{$\SinsemillaHash$} is an algebraic \hashFunction with \collisionResistance (for fixed input length) derived from assumed hardness -of the \xDiscreteLogarithmProblem. It is designed by Sean Bowe and Daira Emma Hopwood. +of the \xDiscreteLogarithmProblem. It is designed by Sean Bowe and \nh{Daira-Emma} Hopwood. The motivation for introducing a new discrete-logarithm-based hash function (rather than using $\PedersenHash$) is to make efficient use of the lookups available in recent proof systems including \HaloTwo. @@ -8838,7 +8881,7 @@ Let $\Uncommitted{Orchard}$ be as defined in \crossref{constants}. \vspace{-0.25ex} Let $\ItoLEOSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$ -and $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ +and $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \binaryrange{\ell}$ be as defined in \crossref{endian}. \vspace{0.5ex} @@ -9024,7 +9067,7 @@ this is a nontrivial discrete logarithm relation between independent bases. \begin{nnotes} \item \cite[Lemma 3]{JT2020} proves a tight reduction from finding a nontrivial discrete logarithm - relation in a prime-order group to solving the \xDiscreteLogarithmProblem in that group. + relation in a \primeOrderGroup to solving the \xDiscreteLogarithmProblem in that group. \item The above theorem easily extends to the case where additional scalar multiplication terms with independent bases may be added to the $\SinsemillaHashToPoint$ output before applying $\ExtractPbot$. This is needed to show security of the $\SinsemillaShortCommitAlg$ \commitmentScheme defined in @@ -9099,14 +9142,14 @@ reference implementation \cite{Poseidon-1.1}.\footnote{\nufive{Previous versions implementation were inconsistent with the paper. For verifying the parameters used in Zcash, we recommend the fork \cite{Poseidon-Zc1.1} which avoids use of the obsolete PyCrypto library.}} -The S-box function is $x \mapsto x^5$. The number of full rounds $R_F$ is $8$, and +The \nh{S-box} function is $x \mapsto x^5$. The number of full rounds $R_F$ is $8$, and the number of partial rounds $R_P$ is $56$. We use $\Poseidon$ in a sponge configuration \cite{BDPA2011} (with elementwise addition in $\GF{\ParamP{q}}$ replacing exclusive-or of bit strings\footnote{\nufive{The sponge construction was originally proposed as operating on an arbitrary group. \cite{BDPA2007}}}) to construct a \hashFunction. The sponge capacity is one field element, the rate is two field elements, and -the output is one field element. We use the ``Constant-Input-Length''\strut mode described in +the output is one field element. We use the \nh{``Constant-Input-Length''} \strut mode described in \cite[section 4.2]{GKRRS2019}: for a $2$-element input, the initial value of the capacity element is $2^{65}$, and no padding of the input message is needed. @@ -9137,14 +9180,14 @@ by \texttt{calc\_round\_numbers.py} in that implementation, for a $128$-bit secu $2^{32} \mult 3 \mult 463 \mult 539204044132271846773 \mult 8999194758858563409123804352480028797519453$. Furthermore, previous cryptanalysis of $\Poseidon$ has focussed mainly on the case - of S-box $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because + of \nh{S-box} $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because $x \mapsto x^3$ would not be a permutation. $\alpha = 5$ is the smallest integer for which $x \mapsto x^\alpha$ is a permutation in $\GF{\ParamP{q}}$. On the other hand, the number of rounds chosen includes a significant security margin, even taking into account these considerations. For small $t$, such as $t = 3$ as used here, the results of \cite{KR2020} are positive for security since they indicate that - the number of active S-boxes through the middle rounds is larger than originally + the number of active \nh{S-boxes} through the middle rounds is larger than originally estimated by the $\Poseidon$ designers (and the number of rounds is based on this original conservative estimate). @@ -9163,7 +9206,7 @@ by \texttt{calc\_round\_numbers.py} in that implementation, for a $128$-bit secu on the \Pallas curve, even if the $\Poseidon$-based PRF were distinguishable from an ideal PRF. \item The constant $2^{65}$ comes from \cite[section 4.2]{GKRRS2019}: - ``Constant-Input-Length Hashing. The capacity value is $\mathit{length} \mult (2^{64}) + (o - 1)$ + ``\nh{Constant-Input-Length} Hashing. The capacity value is $\mathit{length} \mult (2^{64}) + (o - 1)$ where $o$ is the output length.'' In this case the input length ($\mathit{length}$) is $2$ field elements, and the output length is $1$ field element. \end{nnotes} @@ -9390,7 +9433,7 @@ It is instantiated using the $\BlakeTwosGeneric$ \hashFunction defined in \cross \vspace{-2ex} \securityrequirement{ -$\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a +The function $\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a \collisionResistant \xPRF for output range $\byteseq{32}$ when keyed by the bits corresponding to $\NullifierKeyRepr$, with input in the bits corresponding to $\NoteUniqueRandRepr$. Note that @@ -9480,7 +9523,7 @@ $\Key \in \Keyspace$. Similarly, let $\SymDecrypt{\Key}(\Ctext)$ be $\SymSpecific$ decryption of ciphertext $\Ctext \in \Ciphertext$, with empty ``associated data", all-zero nonce $\zeros{96}$, and $256$-bit key -$\Key \in \Keyspace$. The result is either the plaintext byte sequence, +$\Key \in \Keyspace$. The result is either the plaintext \byteSequence, or $\bot$ indicating failure to decrypt. \pnote{ @@ -9539,13 +9582,13 @@ secret keys. Let $\KASproutCurveMultiply(\bytes{n}, \bytes{q})$ be the result of point multiplication of the $\KASproutCurve$ \publicKey represented by the byte sequence $\bytes{q}$ by the $\KASproutCurve$ secret key represented by the -byte sequence $\bytes{n}$, as defined in \cite[section 2]{Bernstein2006}. +\byteSequence $\bytes{n}$, as defined in \cite[section 2]{Bernstein2006}. -Let $\KABase{Sprout} := \KASproutCurveBase$ be the public byte sequence representing +Let $\KABase{Sprout} := \KASproutCurveBase$ be the public \byteSequence representing the $\KASproutCurve$ base point. Let $\KASproutCurveClamp(\bytes{x})$ take a 32-byte sequence $\bytes{x}$ as input -and return a byte sequence representing a $\KASproutCurve$ \privateKey, with +and return a \byteSequence representing a $\KASproutCurve$ \privateKey, with bits ``clamped'' as described in \cite[section 3]{Bernstein2006}: ``clear bits $0, 1, 2$ of the first byte, clear bit $7$ of the last byte, and set bit $6$ of the last byte.'' Here the bits of a byte are numbered @@ -9740,7 +9783,7 @@ Let $a = -1$. Let $d = -121665/121666 \pmod{p}$. Let $\ell = 2^{252} + 27742317777372353535851937790883648493$ (the order of the \EdSpecific -curve's prime-order subgroup). +curve's \primeOrderSubgroup). Let $\EdDSABase$ be the base point given in \cite{BDLSY2012}. @@ -9854,7 +9897,7 @@ to accurately document the history of consensus changes.} \sapling{ \extralabel{concreteredjubjub}{\lsubsubsection{\RedDSAText{}\notnufive{ and \RedJubjubText{}}\notbeforenufive{, \RedJubjubText{}, and \RedPallasText{}}}{concretereddsa}} -$\RedDSA$ is a Schnorr-based \signatureScheme, optionally supporting key re-randomization +$\RedDSA$ is a Schnorr-based \signatureScheme, optionally supporting key \reRandomization as described in \crossref{abstractsigrerand}. It also supports a Secret Key to Public Key Monomorphism as described in \crossref{abstractsigmono}. It is based on a scheme from \cite[section 3]{FKMSSS2016}, with some ideas from @@ -9867,7 +9910,7 @@ The \spendAuthSignatureScheme $\SpendAuthSig{Sapling}$ is instantiated by $\RedJ parameters defined in \crossref{concretespendauthsig}. The \bindingSignatureScheme $\BindingSig{Sapling}$ is instantiated by $\RedJubjub$ without -key re-randomization, using parameters defined in \crossref{concretebindingsig}. +key \reRandomization, using parameters defined in \crossref{concretebindingsig}. \nufive{ $\RedPallas$ is a specialization of $\RedDSA$ to the \pallasCurve defined in \crossref{pallasandvesta}, @@ -9877,7 +9920,7 @@ The \spendAuthSignatureScheme $\SpendAuthSig{Orchard}$ is instantiated by $\RedP parameters defined in \crossref{concretespendauthsig}. The \bindingSignatureScheme $\BindingSig{Orchard}$ is instantiated by $\RedPallas$ without -key re-randomization, using parameters defined in \crossref{concretebindingsig}. +key \reRandomization, using parameters defined in \crossref{concretebindingsig}. } %nufive Let $\ItoLEBSP{}$, $\ItoLEOSP{}$, $\LEOStoIP{}$, and $\LEBStoOSP{}$ be as defined in \crossref{endian}. @@ -9931,7 +9974,7 @@ Define $\RedDSADerivePublic \typecolon \RedDSAPrivate \rightarrow \RedDSAPublic$ \introlist Define $\RedDSAGenRandom \typecolon () \rightarrowR \RedDSARandom$ as: \begin{formulae} - \item Choose a byte sequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. + \item Choose a \byteSequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. \item Return $\RedDSAHashToScalar(T)$. \end{formulae} @@ -9953,7 +9996,7 @@ Define $\RedDSARandomizePublic \typecolon \RedDSARandom \times \RedDSAPublic \ri \introlist Define $\RedDSASign{} \typecolon (\sk \typecolon \RedDSAPrivate) \times (M \typecolon \RedDSAMessage) \rightarrowR \RedDSASignature$ as: \begin{algorithm} - \item Choose a byte sequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. + \item Choose a \byteSequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. \item Let $\vkBytes{} = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\RedDSADerivePublic(\sk)}\kern 0.05em}$. \vspace{-0.75ex} \item Let $r = \RedDSAHashToScalar(T \bconcat \vkBytes{} \bconcat M)$. @@ -10042,8 +10085,8 @@ As required, $\RedDSADerivePublic$ is a group monomorphism, since it is injectiv \end{tabular} \vspace{0.5ex} -A $\RedDSA$ \validatingKey $\vk$ can be encoded as a bit sequence $\reprG{}\Of{\vk}$\, of -length $\ellG{}$ bits (or as a corresponding byte sequence $\vkBytes{}$ by then applying $\LEBStoOSP{\ellG{}}$). +A $\RedDSA$ \validatingKey $\vk$ can be encoded as a \bitSequence $\reprG{}\Of{\vk}$\, of +length $\ellG{}$ bits (or as a corresponding \byteSequence $\vkBytes{}$ by then applying $\LEBStoOSP{\ellG{}}$). \vspace{0.5ex} \introlist @@ -10087,7 +10130,7 @@ Let $\RedJubjub$ be as defined in \crossref{concretereddsa}. Define $\AuthSignBase{Sapling} := \FindGroupJHash\Of{\ascii{Zcash\_G\_}, \ascii{}}$. The \defining{\spendAuthSignatureScheme} $\SpendAuthSig{Sapling}$ is instantiated as $\RedJubjub$ -with key re-randomization and with generator $\GenG{} = \AuthSignBase{Sapling}$. +with key \reRandomization and with generator $\GenG{} = \AuthSignBase{Sapling}$. \nufive{ Let $\RedPallas$ be as defined in \crossref{concretereddsa}. @@ -10095,7 +10138,7 @@ Let $\RedPallas$ be as defined in \crossref{concretereddsa}. Define $\AuthSignBase{Orchard} := \GroupPHash\Of{\ascii{z.cash:Orchard}, \ascii{G}}$. The \defining{\spendAuthSignatureScheme} $\SpendAuthSig{Orchard}$ is instantiated as $\RedPallas$ -with key re-randomization and with generator $\GenG{} = \AuthSignBase{Orchard}$. +with key \reRandomization and with generator $\GenG{} = \AuthSignBase{Orchard}$. } %nufive \vspace{0.5ex} @@ -10103,7 +10146,7 @@ See \crossref{spendauthsig} for details on the use of this \signatureScheme. \vspace{-2ex} \securityrequirement{ -\nufive{Each instantiation of} $\SpendAuthSig{}$ must be a SURK-CMA secure \rerandomizableSignatureScheme +\nufive{Each instantiation of} $\SpendAuthSig{}$ must be a \nh{SURK-CMA-secure} \rerandomizableSignatureScheme as defined in \crossref{abstractsigrerand}. } %securityrequirement } %sapling @@ -10117,18 +10160,18 @@ as defined in \crossref{abstractsigrerand}. Let $\RedJubjub$\nufive{ and $\RedPallas$} be as defined in \crossref{concreteredjubjub}. The \Sapling{} \defining{\bindingSignatureScheme}, $\BindingSig{Sapling}$, is instantiated as $\RedJubjub$ -without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Sapling}$ defined in +without key \reRandomization, using generator $\GenG{} = \ValueCommitRandBase{Sapling}$ defined in \crossref{concretevaluecommit}. See \crossref{saplingbalance} for details on the use of this \signatureScheme. \nufive{ The \Orchard{} \defining{\bindingSignatureScheme}, $\BindingSig{Orchard}$, is instantiated as $\RedPallas$ -without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Orchard}$ defined in +without key \reRandomization, using generator $\GenG{} = \ValueCommitRandBase{Orchard}$ defined in \crossref{concretevaluecommit}. See \crossref{orchardbalance} for details on the use of this \signatureScheme. } %nufive \vspace{-2ex} \securityrequirement{ -\nufive{Each instantiation of} $\BindingSig{}$ must be a SUF-CMA secure \keyMonomorphicSignatureScheme +\nufive{Each instantiation of} $\BindingSig{}$ must be a \nh{SUF-CMA-secure} \keyMonomorphicSignatureScheme as defined in \crossref{abstractsigmono}. A signature must prove knowledge of the discrete logarithm of the \validatingKey with respect to the base $\ValueCommitRandBase{Sapling}$\nufive{ or $\ValueCommitRandBase{Orchard}$}. @@ -10223,7 +10266,7 @@ instantiated as follows using $\WindowedPedersenCommitAlg$: (see \crossref{saplingmerklecrh}). The prefix $\ones{6}$ distinguishes the use of $\WindowedPedersenCommitAlg$ in $\NoteCommitAlg{Sapling}$ from the layer prefix used in $\MerkleCRH{Sapling}$. - That layer prefix is a $6$-bit little-endian encoding of an integer + That layer prefix is a $6$-bit \littleEndian encoding of an integer in the range $\range{0}{\MerkleDepth{Sapling}-1}$; because $\MerkleDepth{Sapling} < 64$, it cannot collide with $\ones{6}$. \item The arguments to $\NoteCommitAlg{Sapling}$ are in a different order to their encodings @@ -10346,7 +10389,7 @@ which is equivalent to: \vspace{-1ex} \nnote{The output of $\HomomorphicPedersenCommit{Sapling}{}$ may (with negligible probability for a randomly -chosen \commitmentTrapdoor) be the zero point $\ZeroJ$. This would be rejected by consensus if it appeared as +chosen \commitmentTrapdoor) be the zero point of the curve, $\ZeroJ$. This would be rejected by consensus if it appeared as the $\cv$ field of a \spendDescription (\crossref{spenddesc}) or \outputDescription (\crossref{outputdesc}). An implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$.} @@ -10610,7 +10653,7 @@ For a point $P \typecolon \SubgroupGstar{2} = (\xP, \yP)$: \item A rational point $P \neq \ZeroG{2}$ on the curve $\CurveG{2}$ can be verified to be of order $\ParamG{r}$, and therefore in $\SubgroupGstar{2}$, by checking that $\ParamG{r} \mult P = \ZeroG{2}$. - \item The use of big-endian order by $\ItoBEBSP{}$ is different from the encoding + \item The use of \bigEndian order by $\ItoBEBSP{}$ is different from the encoding of most other integers in this protocol. The encodings for $\SubgroupGstar{1, 2}$ are consistent with the definition of $\ECtoOSP{}$ for compressed curve points in @@ -10757,11 +10800,11 @@ For a point $P \typecolon \SubgroupSstar{2} = (\xP, \yP)$: \item The points at infinity $\ZeroS{1, 2}$ never occur in proofs and have no defined encodings in this protocol. \item In contrast to the corresponding \BNPairing curve, $\CurveS{1}$ over $\GF{\ParamS{q}}$ - is \emph{not} of prime order. + is \emph{not} a \primeOrderCurve. \item A rational point $P \neq \ZeroS{i}$ on the curve $\CurveS{i}$ for $i \in \setof{1, 2}$ can be verified to be of order $\ParamS{r}$, and therefore in $\SubgroupSstar{i}$, by checking that $\ParamS{r} \mult P = \ZeroS{i}$. - \item The use of big-endian order by $\ItoBEBSP{}$ is different from the encoding + \item The use of \bigEndian order by $\ItoBEBSP{}$ is different from the encoding of most other integers in this protocol. \item The encodings for $\SubgroupSstar{1, 2}$ are specific to \Zcash. \item Algorithms for decompressing points from the encodings of @@ -11160,8 +11203,8 @@ can only be $0$ when $P = \ZeroP$.} \Orchard uses the ``simplified SWU'' algorithm for \randomOracleAdjective hashing to elliptic curves with $j$-invariant $0$, consistent with \cite[section 6.6.3]{ID-hashtocurve}, based on a method by Riad Wahby and Dan Boneh \cite{WB2019}. -It is adapted from work of Eric Brier, Jean-Sébastien Coron, Thomas Icart, David Madore, -Hugues Randriam, and Mehdi Tibouchi in \cite{BCIMRT2010}; Andrew Shallue and Christiaan {van de Woestijne} +It is adapted from work of Eric Brier, \nh{Jean-Sébastien} Coron, Thomas Icart, David Madore, +Hugues Randriam, and Mehdi Tibouchi in \cite{BCIMRT2010}; Andrew Shallue and Christiaan van~de~Woestijne in \cite{SvdW2006}; and Maciej Ulas in \cite{Ulas2007}. Let $\GroupP$ and $\GroupV$ be the represented groups of points on the \pallasCurve and the @@ -11291,7 +11334,7 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type \item Unlike other uses of $\BlakeTwobGeneric$ in \Zcash, zero bytes are used for the $\BlakeTwobGeneric$ personalization, in order to follow the Internet Draft which encodes $\DST$ in the hash inputs instead. - \item The conversion from bytes to field elements uses big-endian order, again in order + \item The conversion from bytes to field elements uses \bigEndian order, again in order to follow the Internet Draft\rlap{.} \item A minor optimization is to cache the state of the $\BlakeTwob{512}$ instance used to compute $b_0$ after processing $\zerobytes{128}$, since this state does @@ -11349,7 +11392,7 @@ Let $\GroupGHashInput := \byteseqs \times \byteseqs$. The first input element acts as a domain separator to distinguish uses of the \groupHash for different purposes; the second input element is the message. -This hash-to-curve algorithm does not have a URS, i.e.\ $\GroupGHashURSType := ()$. +This \hashToCurve algorithm does not have a URS, i.e.\ $\GroupGHashURSType := ()$. \introlist The hash $\GroupGHash(D \typecolon \byteseqs, M \typecolon \byteseqs) \typecolon \GroupG{}$ @@ -11374,7 +11417,7 @@ is calculated as follows: to the Internet Draft, the definition here takes precedence. \item It is not necessary to use the $\clearcofactor$ function specified in the Internet Draft, because \Pallas and \Vesta (and therefore \IsoPallas and \IsoVesta) - are prime-order. + are \primeOrderCurves. \item The above description incorporates optimizations from \cite{WB2019} that avoid inversions and unnecessary square tests in the computation of $\maptocurvesimpleswuIsoG$. In order to fully avoid inversions, the output of $\maptocurvesimpleswuIsoG$ can be @@ -11502,7 +11545,7 @@ verifier \MUST check, for the encoding of each element, that: \vspace{-0.5ex} \item the lead byte is of the required form; \vspace{-0.5ex} - \item the remaining bytes encode a big-endian representation of an integer in + \item the remaining bytes encode a \bigEndian representation of an integer in $\range{0}{\ParamS{q}\!-\!1}$ or (for $\Proof{B}$) $\range{0}{\ParamSexp{q}{2}\!-\!1}$; \vspace{-0.5ex} @@ -11577,7 +11620,7 @@ verifier \MUST check, for the encoding of each element, that: \vspace{-0.5ex} \item the leading bitfield is of the required form; \vspace{-0.5ex} - \item the remaining bits encode a big-endian representation of an integer + \item the remaining bits encode a \bigEndian representation of an integer in $\range{0}{\ParamS{q}\!-\!1}$ or (in the case of $\Proof{B}$) two integers in that range; \vspace{-0.5ex} @@ -11600,7 +11643,7 @@ For \Orchard \actionDescriptions in version 5 \transactions, \Zcash uses \zkSNAR \lsubsubsubsubsection{Encoding of \HaloTwoText{} Proofs}{halo2encoding} \vspace{-1ex} -\HaloTwo proofs are defined as byte sequences, and so the encoding is the proof itself. +\HaloTwo proofs are defined as \byteSequences, and so the encoding is the proof itself. } %nufive @@ -11664,9 +11707,9 @@ The encoding of a \SaplingOrOrchard \notePlaintext consists of: This section describes how \Zcash encodes \shieldedPaymentAddresses, \incomingViewingKeys, and \spendingKeys. -Addresses and keys can be encoded as a byte sequence; this is called +Addresses and keys can be encoded as a \byteSequence; this is called the \defining{\rawEncoding}. For \Sprout \shieldedPaymentAddresses, this -byte sequence can then be further encoded using \BaseFiftyEightCheck. The \BaseFiftyEightCheck +\byteSequence can then be further encoded using \BaseFiftyEightCheck. The \BaseFiftyEightCheck layer is the same as for upstream \Bitcoin addresses \cite{Bitcoin-Base58}. \sapling{ @@ -11946,7 +11989,7 @@ When decoding the representation of $\DiversifiedTransmitPublic$, the address \M considered invalid if $\abstJ$ returns $\bot$. \nufive{\cite{ZIP-216} specifies that the address \MUST also be considered invalid if the -resulting $\DiversifiedTransmitPublic$ is not in the prime-order subgroup $\SubgroupJ$, or +resulting $\DiversifiedTransmitPublic$ is not in the \primeOrderSubgroup $\SubgroupJ$, or if it is a \nonCanonicalPoint encoding as defined in \crossref{abstractgroup}. This \MAY be enforced in advance of activation of \NUFive.} @@ -11982,7 +12025,7 @@ The \rawEncoding of a \Sapling \incomingViewingKey consists of: \vspace{-1.5ex} \begin{itemize} - \item $32$ bytes (little-endian) specifying $\InViewingKey$, padded with zeros in the most + \item $32$ bytes (\littleEndian) specifying $\InViewingKey$, padded with zeros in the most significant bits. \end{itemize} @@ -12187,7 +12230,7 @@ The \rawEncoding of an \Orchard \incomingViewingKey consists of: \vspace{-2.5ex} \begin{itemize} \item $32$ bytes specifying $\DiversifierKey$. - \item $32$ bytes (little-endian) specifying $\InViewingKey$. + \item $32$ bytes (\littleEndian) specifying $\InViewingKey$. \end{itemize} \vspace{-1.5ex} @@ -12234,9 +12277,9 @@ The \rawEncoding of an \Orchard \fullViewingKey consists of: \vspace{-2.5ex} \begin{itemize} - \item $32$ bytes (little-endian) specifying $\AuthSignPublic$. - \item $32$ bytes (little-endian) specifying $\NullifierKey$. - \item $32$ bytes (little-endian) specifying $\CommitIvkRand$. + \item $32$ bytes (\littleEndian) specifying $\AuthSignPublic$. + \item $32$ bytes (\littleEndian) specifying $\NullifierKey$. + \item $32$ bytes (\littleEndian) specifying $\CommitIvkRand$. \end{itemize} \introlist @@ -12297,7 +12340,7 @@ encoded in \libsnark format, are: \end{lines} \vspace{-0.5ex} -These parameters were obtained by a multi-party computation described in +These parameters were obtained by a \multiPartyComputation described in \cite{BGG-mpc} and \cite{BGG2017}. \sapling{They are used only before \Sapling activation.} Due to the security vulnerability described in \crossref{bctv}, it is not recommended to use these parameters in new protocols, and it is recommended to @@ -12323,7 +12366,7 @@ the \Sprout \joinSplitCircuit used after \Sapling activation, are respectively: \texttt{d5054e371842b3f88fa1b9d7e8e075249b3ebabd167fa8b0f3161292d36c180a sprout-groth16.params} \end{lines} -These parameters were obtained by a multi-party computation described in \cite{BGM2017}. +These parameters were obtained by a \multiPartyComputation described in \cite{BGM2017}. } %sapling @@ -12334,7 +12377,7 @@ These parameters were obtained by a multi-party computation described in \cite{B Let $\URS := \ascii{096b36a5804bfacef1691e173c366a47ff5ba84a44f26ddd7e8d9f79d5b42df0}$. This value is used in the definition of $\GroupJHash{}$ in \crossref{concretegrouphashjubjub}, -and in the multi-party computation to obtain the \Sapling parameters given in +and in the \multiPartyComputation to obtain the \Sapling parameters given in \crossref{grothparameters}. \introlist @@ -12342,13 +12385,13 @@ It is derived as described in \cite{Bowe2018}: \begin{itemize} \item Take the hash of the \Bitcoin \block at height $514200$ in \rpcByteOrder, - i.e.\ the big-endian $32$-byte representation of $\hexint{00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58}$. + i.e.\ the \bigEndian $32$-byte representation of $\hexint{00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58}$. \item Apply \shaHash $2^{42}$ times. - \item Convert to a US-ASCII lowercase hexadecimal string. + \item Convert to a \xUSASCII lowercase hexadecimal string. \end{itemize} \vspace{-2ex} -\pnote{$\URS$ is a $64$-byte US-ASCII string, i.e.\ the first byte is \hexint{30}, not \hexint{09}.} +\pnote{$\URS$ is a $64$-byte \xUSASCII string, i.e.\ the first byte is \hexint{30}, not \hexint{09}.} } %sapling @@ -12408,7 +12451,7 @@ Each \networkUpgrade is introduced as a \end{itemize} Full support for each \networkUpgrade is indicated by a minimum version -of the peer-to-peer protocol. At the planned \activationHeight, +of the \peerToPeerProtocol. At the planned \activationHeight, nodes that support a given upgrade will disconnect from (and will not reconnect to) nodes with a protocol version lower than this minimum. \overwinter{See \cite{ZIP-201} for how this applies to the \Overwinter @@ -12675,7 +12718,7 @@ of the \transaction encoding in the \notbeforenufive{pre-v5} format described ab \nufive{ The \transactionID of a version 5 \transaction is as defined in \cite{ZIP-244}. A v5 -\transaction also has a \wtxid (used for example in the peer-to-peer protocol) as defined +\transaction also has a \wtxid (used for example in the \peerToPeerProtocol) as defined in \cite{ZIP-239}. } %nufive @@ -12756,7 +12799,7 @@ in \cite{ZIP-239}. \item A \coinbaseTransaction for a \block at \blockHeight greater than $0$ \MUST have a script that, as its first item, encodes the \blockHeight $\BlockHeight$ as follows. For $\BlockHeight$ in the range $\range{1}{16}$, the encoding is a single byte of value $\hexint{50} + \BlockHeight$. - Otherwise, let $\heightBytes$ be the signed little-endian representation of $\BlockHeight$, + Otherwise, let $\heightBytes$ be the signed \littleEndian representation of $\BlockHeight$, using the minimum nonzero number of bytes such that the most significant byte is $< \hexint{80}$. The length of $\heightBytes$ \MUST be in the range $\range{1}{5}$. Then the encoding is the length of $\heightBytes$ encoded as one byte, followed by $\heightBytes$ itself. This matches @@ -13206,7 +13249,7 @@ $1344$ & $\solution$ & \type{byte[1344]} & The \Equihash solution. \\ \hline \vspace{2ex} A \block consists of a \blockHeader and a sequence of \transactions. How transactions -are encoded in a \block is part of the Zcash peer-to-peer protocol but not part of +are encoded in a \block is part of the Zcash \peerToPeerProtocol but not part of the consensus protocol. \vspace{1ex} @@ -13342,12 +13385,12 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin- \introsection \lsubsection{Proof of Work}{pow} -\Zcash uses \Equihash \cite{BK2016} as its Proof of Work. The original motivations for -changing the Proof of Work from \shadHash used by \Bitcoin were described in \cite{WG2016}. +\Zcash uses \Equihash \cite{BK2016} as its \proofOfWork. The original motivations for +changing the \proofOfWork from \shadHash used by \Bitcoin were described in \cite{WG2016}. \vspace{1ex} \introlist -A \block satisfies the Proof of Work if and only if: +A \block satisfies the \proofOfWork if and only if: \begin{itemize} \item The $\solution$ field encodes a \validEquihashSolution according to \crossref{equihash}. @@ -13473,10 +13516,10 @@ and so the first $7$ bytes of $\solution$ would be $[0, 2, 32, 0, 10, 127, 255]$. \pnote{ -$\ItoBEBSP{}$ is big-endian, while integer field encodings in $\powheader$ -and in the instantiation of $\EquihashGen{}$ are little-endian. -The rationale for this is that little-endian serialization of -\blockHeaders is consistent with \Bitcoin, but little-endian +$\ItoBEBSP{}$ is \bigEndian, while integer field encodings in $\powheader$ +and in the instantiation of $\EquihashGen{}$ are \littleEndian. +The rationale for this is that \littleEndian serialization of +\blockHeaders is consistent with \Bitcoin, but \littleEndian ordering of bits in the solution encoding would require bit-reversal (as opposed to only shifting). } @@ -13490,7 +13533,7 @@ Difficulty is defined in terms of a \targetThreshold, which is adjusted for each The difficulty filter is unchanged from \Bitcoin, and is calculated using \shadHash on the whole \blockHeader (including $\solutionSize$ and $\solution$). -The result is interpreted as a $256$-bit integer represented in little-endian +The result is interpreted as a $256$-bit integer represented in \littleEndian byte order, which \MUST be less than or equal to the \targetThreshold given by $\ToTarget(\nBitsField)$. @@ -13999,7 +14042,7 @@ for which the ``height in coinbase'' was inadvertently omitted. in \crossref{transparentaddrencoding}. \introlist -\cite{BIP-111} applies from peer-to-peer network protocol version $170004$ onward; that is: +\cite{BIP-111} applies from \peerToPeerProtocol version $170004$ onward; that is: \begin{itemize} \item references to protocol version $70002$ are to be replaced by $170003$; \item references to protocol version $70011$ are to be replaced by $170004$; @@ -14078,7 +14121,7 @@ as input, allowing \joinSplitTransfers to subsume the functionality of Mints. An advantage of this is that a \Zcash \transaction that takes input from a \utxo can produce up to $\NNew$ output \notes, improving the indistinguishability properties of the protocol. A related change -conceals the input arity of the \joinSplitTransfer: an unused (zero-value) +conceals the input arity of the \joinSplitTransfer: an unused (zero-valued) input is indistinguishable from an input that takes value from a \note. } @@ -14290,7 +14333,7 @@ attacker, with a work factor on the order of $2^{64}$, to find distinct pairs $(\AuthPublic, \NoteUniqueRand)$ and $(\AuthPublic\!', \NoteUniqueRand')$ with colliding outputs of the truncated hash, and therefore the same \noteCommitment. This would have allowed such an attacker to break the -Balance property by double-spending \notes, potentially creating arbitrary +Balance property by \doubleSpending \notes, potentially creating arbitrary amounts of currency for themself \cite{HW2016}. \Zcash uses a simpler construction with a single hash evaluation for the @@ -14444,8 +14487,8 @@ $\InViewingKey$ is removed. \lsubsection{In-band secret distribution}{inbandrationale} \Zerocash specified ECIES (referencing Certicom's SEC 1 standard) as the -encryption scheme used for the in-band secret distribution. This has been -changed to a key agreement scheme based on $\KASproutCurve$ (for \Sprout)\sapling{ or +encryption scheme used for the \inBand secret distribution. This has been +changed to a \keyAgreementScheme based on $\KASproutCurve$ (for \Sprout)\sapling{ or \Jubjub (for \Sapling)} and the authenticated encryption algorithm $\SymSpecific$. This scheme is still loosely based on ECIES, and on the $\CryptoBoxSeal$ scheme defined in libsodium \cite{libsodium-Seal}. @@ -14455,7 +14498,7 @@ The motivations for this change were as follows: \begin{itemize} \item The \Zerocash paper did not specify the curve to be used. - We believe that $\KASproutCurve$ has significant side-channel resistance, + We believe that $\KASproutCurve$ has significant \sideChannel resistance, performance, implementation complexity, and robustness advantages over most other available curve choices, as explained in \cite{Bernstein2006}. \sapling{For \Sapling, the \jubjubCurve was designed according to a @@ -14463,7 +14506,7 @@ The motivations for this change were as follows: \cite{BL-SafeCurves} \cite{Hopwood2018}. This retains $\KASproutCurve$'s advantages while keeping \shieldedPaymentAddress sizes short, because the same \publicKey material supports both encryption and - spend authentication.} \nufive{For \Orchard, we define a prime-order curve + spend authentication.} \nufive{For \Orchard, we define a \primeOrderCurve \Pallas \cite{Hopwood2020}, with similar advantages to \Jubjub.} \item ECIES permits many options, which were not specified. There are at least --counting conservatively-- 576 possible combinations of options and @@ -14545,7 +14588,7 @@ expected to cause any weakness in \note encryption. For all shielded protocols, the checking of \noteCommitments makes \defining{\partitioningOracleAttacks} \cite{LGR2021} against the \noteCiphertext -infeasible, at least in the absence of side-channel attacks. \sapling{The following +infeasible, at least in the absence of \sideChannel attacks. \sapling{The following argument applies to \Sapling\nufive{ and \Orchard}, but can be adapted to \Sprout by replacing $\InViewingKey$ with $\TransmitPrivate$, $\DiversifiedTransmitPublic$ with $\TransmitPublic$, and using a fixed base. The decryption procedure @@ -14588,7 +14631,7 @@ Suppose that an adversary finds a collision on $\PRFaddr{}$ such that $\AuthPrivateSup{1}$ and $\AuthPrivateSup{2}$ are distinct \spendingKeys for the same $\AuthPublic$. Because the \noteCommitment is to $\AuthPublic$, but the \nullifier is computed from $\AuthPrivate$ (and $\NoteUniqueRand$), -the adversary is able to double-spend the note, once with each $\AuthPrivate$. +the adversary is able to \doubleSpend the note, once with each $\AuthPrivate$. This is not detected because each Spend reveals a different \nullifier. The \joinSplitStatements are still valid because they can only check that the $\AuthPrivate$ in the witness is \emph{some} preimage of @@ -14665,15 +14708,15 @@ distinct openings of the \noteCommitment when Condition I or II is violated. \introlist \lsection{Acknowledgements}{acknowledgements} -The inventors of \Zerocash are Eli Ben-Sasson, Alessandro Chiesa, +The inventors of \Zerocash are Eli \nh{Ben-Sasson}, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. The designers of the \Zcash protocol are the \Zerocash inventors -and also Daira Emma Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornby, -Nathan Wilcox, Zooko Wilcox, Jay Graber, Eirik Ogilvie-Wigley, Ariel Gabizon, +and also \nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornby, +Nathan Wilcox, Zooko Wilcox, Jay Graber, Eirik \nh{Ogilvie-Wigley}, Ariel Gabizon, George Tankersley, Ying~Tong Lai, Kris Nuttycombe, Jack Gavigan, Steven Smith, and Greg Pfeil. -The \Equihash proof-of-work algorithm was designed by Alex Biryukov and +The \Equihash \proofOfWork algorithm was designed by Alex Biryukov and Dmitry Khovratovich. The authors would like to thank everyone with whom they have discussed the @@ -14683,12 +14726,12 @@ Samantha Hulsey, Alex Balducci, Jake Tarren, Solar Designer, Ling Ren, John Tromp, Paige Peterson, jl777, Alison Stevenson, Maureen Walsh, Filippo Valsorda, Zaki Manian, Kexin Hu, Brian Warner, Mary Maller, Michael Dixon, Andrew Poelstra, Benjamin Winston, Josh Cincinnati, -Kobi Gurkan, Weikeng Chen, Henry de Valence, Deirdre Connolly, Chelsea Komlo, -Zancas Wilcox, Jane Lusby, Teor, Izaak Meckler, Zac Williamson, Vitalik Buterin, +Kobi Gurkan, Weikeng Chen, Henry de~Valence, Deirdre Connolly, Chelsea Komlo, +Zancas Wilcox, Jane Lusby, teor, Izaak Meckler, Zac Williamson, Vitalik Buterin, Jakub Zalewski, Oana Ciobotaru, Andre Serrano, Brad Miller, Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, -Kevin Gorham, Larry Ruane, Marshall Gaucher, Ryan Taylor, Sasha Meyer, and no -doubt others. +Kevin Gorham, Larry Ruane, Marshall Gaucher, Ryan Taylor, Sasha Meyer, +Conrado Gouvea, and no doubt others. We would also like to thank the designers and developers of \Bitcoin and \BitcoinCore. @@ -14699,12 +14742,16 @@ for \HaloTwo (any remaining errors are ours). The Faerie Gold attack was found by Zooko Wilcox (who also came up with the name) and Brian Warner. The fix for this attack in \Sprout was proposed by -Daira Emma Hopwood; subsequent analysis of variations on the attack was -performed by Daira Emma Hopwood and Sean Bowe. The internal hash collision -attack was found by Taylor Hornby. The error in the \Zerocash proof of -Balance relating to \collisionResistance of $\PRFaddr{}$ was found by -Daira Emma Hopwood. The errors in the proof of Ledger Indistinguishability -mentioned in \crossref{truncation} were also found by Daira Emma Hopwood. +\nh{Daira-Emma} Hopwood; subsequent analysis of variations on the attack was +performed by \nh{Daira-Emma} Hopwood and Sean Bowe. + +The internal hash collision attack was found by Taylor Hornby. + +The error in the \Zerocash proof of Balance relating to \collisionResistance +of $\PRFaddr{}$ was found by \nh{Daira-Emma} Hopwood. + +The errors in the proof of Ledger Indistinguishability mentioned in +\crossref{truncation} were also found by \nh{Daira-Emma} Hopwood. The 2015 Soundness vulnerability in \BCTV \cite{Parno2015} was found by Bryan Parno. An additional condition needed to resist this attack was @@ -14713,11 +14760,11 @@ The 2019 Soundness vulnerability in \BCTV \cite{Gabizon2019} was found by Ariel Gabizon. The design of \Sapling is primarily due to Matthew Green, Ian Miers, -Daira Emma Hopwood, Sean Bowe, Jack Grigg, and Jack Gavigan. A potential attack +\nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, and Jack Gavigan. A potential attack linking \diversifiedPaymentAddresses, avoided in the adopted design, was found by Brian Warner. -The design of \Orchard is primarily due to Daira Emma Hopwood, Sean Bowe, Jack Grigg, +The design of \Orchard is primarily due to \nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, Kris Nuttycombe, Ying~Tong Lai, and Steven Smith. The observation in \crossref{concretediversifyhash} that @@ -14730,8 +14777,8 @@ used in \crossref{grothbatchverify}, by applying them to \BCTV. The arithmetization used by \HaloTwo is based on that used by \PLONK \cite{GWC2019}, which was designed by Ariel Gabizon, Zachary Williamson, and Oana Ciobotaru. -Numerous people have contributed to the science of zero-knowledge proving -systems, but we would particularly like to acknowledge the work of +Numerous people have contributed to the science of \zeroKnowledgeProvingSystems, +but we would particularly like to acknowledge the work of Shafi Goldwasser, Silvio Micali, Oded Goldreich, Mihir Bellare, Charles Rackoff, Rosario Gennaro, Bryan Parno, Jon Howell, Craig Gentry, Mariana Raykova, Jens Groth, Rafail Ostrovsky, and Amit Sahai. @@ -14742,12 +14789,12 @@ Josh Cincinnati, Tanya Karsou, Henrik Jose, Chris Ward, and others for their work on the Zero Knowledge Podcast, ZK Summits, and ZK Study Club. These efforts have enriched the zero knowledge community immeasurably. -Many of the ideas used in \Zcash{} ---including the use of zero-knowledge proofs +Many of the ideas used in \Zcash{} ---including the use of \zeroKnowledgeProofs to resolve the tension between privacy and auditability, Merkle trees over note commitments (using Pedersen hashes as in \Sapling), and the use of ``serial numbers'' or \nullifiers to detect or prevent -double-spends--- were first applied to privacy-preserving digital currencies -by Tomas Sander and Amnon Ta-Shma. To a large extent \Zcash is a refinement +\doubleSpends--- were first applied to privacy-preserving digital currencies +by Tomas Sander and Amnon \nh{Ta-Shma}. To a large extent \Zcash is a refinement of their ``Auditable, Anonymous Electronic Cash'' proposal in \cite{ST1999}. We thank Alexandra Elbakyan for her tireless work in dismantling barriers @@ -14764,6 +14811,17 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \intropart \lsection{Change History}{changehistory} +\historyentry{Unreleased}{2024-04-14} + +\begin{itemize} + \item Add the hyphen in \nh{Daira-Emma} Hopwood. + \item Correct some author lists in the References. + \item Prevent incorrect line-breaking on hyphens. + \item In \crossref{concretesinsemillahash}, declare use of $\LEBStoIP{}$ instead of $\LEOStoIP{}$. + \item Add an acknowledgement to Conrado Gouvea for discussions on the Zcash protocol. +\end{itemize} + + \historyentry{2023.4.0}{2023-12-19} \begin{itemize} @@ -14795,14 +14853,14 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item In the discussion of partitioning oracle attacks on \note encryption in \crossref{inbandrationale}, we now use the fact that $\DiversifiedTransmitBase$ has order greater than the maximum value of $\InViewingKey$, rather than assuming that $\DiversifiedTransmitBase$ is a non-zero point - in the prime-order subgroup. (In the case of \Sapling, the circuits only enforce that - $\DiversifiedTransmitBase$ is not a small-order point, not that it is in the prime-order - subgroup. It is true that honestly generated addresses have prime-order $\DiversifiedTransmitBase$ + in the \primeOrderSubgroup. (In the case of \Sapling, the circuits only enforce that + $\DiversifiedTransmitBase$ is not a \smallOrderAdjective point, not that it is in the \primeOrderSubgroup. + It is true that honestly generated addresses have \primeOrderAdjective $\DiversifiedTransmitBase$ which would have been sufficient for the security argument against this class of attacks, but the chosen fix is more direct.) \item Delete a confusing claim in \crossref{spenddesc} that ``The check that $\AuthSignRandomizedPublic$ - is not of small order is technically redundant with a check in the \spendCircuit ...''. - The small-order check excludes the zero point $\ZeroJ$, which the \snarkref{Spend authority}{spendauthority} + is not of \smallOrder is technically redundant with a check in the \spendCircuit ...''. + The \smallOrderAdjective check excludes the zero point $\ZeroJ$, which the \snarkref{Spend authority}{spendauthority} check that this claim was intending to reference does not. \item An implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$, in order to avoid @@ -14822,11 +14880,11 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item The abstract no longer describes the \NUFive version of the specification as a draft. } \item Acknowledge Greg Pfeil as a co-designer of the \Zcash protocol. - \item Acknowledge Daira Emma Hopwood for the fix to the Faerie Gold attack in \Sprout, and add a reference + \item Acknowledge \nh{Daira-Emma} Hopwood for the fix to the Faerie Gold attack in \Sprout, and add a reference to hir \textsl{Explaining the Security of Zcash} talk at Zcon3 \cite{Hopwood2022} for repairs to the \Zerocash security definitions. \item Acknowledge the font designers Pablo Impallari and Morris Fuller. - \item Change Daira Emma Hopwood's name. + \item Change \nh{Daira-Emma} Hopwood's name. \end{itemize} @@ -14917,7 +14975,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. apply only when $\effectiveVersion \geq 5$ (since v4 \transactions did not explicitly encode the \nConsensusBranchId{} field). \item Correction in \crossref{constants}: - $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$ is not a bit sequence. + $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$ is not a \bitSequence. \item In \crossref{txnencoding}, add the calculation for \sizeProofsOrchard{} to the v5 \transaction format table. } @@ -15046,8 +15104,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. may be sampled from $\range{0}{2^{128}-1}$ instead of $\range{1}{2^{128}-1}$. \item Add note in \crossref{inbandrationale} about resistance of \note encryption to \partitioningOracleAttacks \cite{LGR2021}. - \item Add acknowledgement to Mihir Bellare for contributions to the science of zero-knowledge - proofs. + \item Add acknowledgement to Mihir Bellare for contributions to the science of \zeroKnowledgeProofs. \item Add acknowledgement to Sasha Meyer. \end{itemize} @@ -15065,7 +15122,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. $\rt{Orchard} \in \GroupP_{\!x}$ would require a square root and is unnecessary. \item Witness $\DiversifiedTransmitBaseNew$ and $\DiversifiedTransmitPublicNew$ in the \Orchard \actionCircuit as $\GroupPstar$, i.e.\ non-identity Pallas points, - rather than witnessing their representations as bit sequences. This reflects + rather than witnessing their representations as \bitSequences. This reflects the existing \zcashd implementation. \item Note that $\AuthSignPublicPoint$ in \Orchard cannot be the identity. } %nufive @@ -15108,9 +15165,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2021.2.13}{2021-07-29} \begin{itemize} - \item Add consensus rules in \crossref{notecommitmenttrees} that a \block \MUSTNOT add - \noteCommitments that exceed the capacity of any of the \Sprout\sapling{ or - \Sapling}\nufive{ or \Orchard} \noteCommitmentTrees. + \item Add consensus rules in \crossref{notecommitmenttrees} that, for each \noteCommitmentTree, + a \block \MUSTNOT add \noteCommitments that exceed the capacity of that tree. \end{itemize} @@ -15217,7 +15273,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \nufive{ \item Correct the type of $\Uncommitted{Orchard}$, which should be $\GroupP_{\!x}$ rather than a - bit sequence. + \bitSequence. \item Explicitly say that padding in \crossref{concretesinsemillahash} is by appending zero bits. \item Add a step to the algorithm for generating an \Orchard \note in \crossref{orchardsend}, to restart if $\EphemeralPrivate = 0$. @@ -15301,7 +15357,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. $\barerange{1}{16}$. \item Clarify, in \crossref{blockchain}, requirements on the range of \blockHeights that should be supported. - \item Delete the sentence ``All conversions between \EdSpecific points, byte sequences, + \item Delete the sentence ``All conversions between \EdSpecific points, \byteSequences, and integers used in this section are as specified in \cite{BDLSY2012}.'' from \crossref{concreteed25519}. This sentence was misleading given that the conversions in $\cite{BDLSY2012}$ are not sufficiently well-specified for a consensus @@ -15447,7 +15503,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. } %nufive \sapling{ \item Fix type error in $\kdfinput$ for $\KDF{Sapling}$\nufive{ and $\KDF{Orchard}$} - ($\ephemeralKey$ is already a byte sequence). + ($\ephemeralKey$ is already a \byteSequence). \item Make a note in \crossref{inbandrationale} of the divergence of $\InViewingKey$ for \SaplingAndOrchard from a uniform scalar. } %sapling @@ -15462,7 +15518,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2021.1.20}{2021-03-25} \begin{itemize} - \item Credit Eirik Ogilvie-Wigley as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller, + \item Credit Eirik \nh{Ogilvie-Wigley} as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller, Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, Kevin Gorham, Larry Ruane, Marshall Gaucher, and Ryan Taylor to the acknowledgements. \nufive{ @@ -15643,10 +15699,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \sapling{ \item Correct the \Sapling \note decryption algorithms: \begin{itemize} - \item $\ephemeralKey$ is kept as a byte sequence rather than immediately converted to a + \item $\ephemeralKey$ is kept as a \byteSequence rather than immediately converted to a curve point; this matters because of \nonCanonicalPoint encoding. \item The representation of $\DiversifiedTransmitPublic$ in a \notePlaintext may also be - \nonCanonicalPoint and need not be in the prime subgroup. + \nonCanonicalPoint and need not be in the \primeOrderSubgroup. \item Move checking of $\cmU$ in decryption with $\InViewingKey$ to the end of the algorithm, to more closely match the implementation. \item The note about decryption of outputs in \mempool \transactions should have been @@ -15675,7 +15731,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. (This rule was correctly implemented in \zcashd.) \sapling{ \item Fix a type error in the output of $\PRFnf{Sapling}{}$; a \Sapling \nullifier is a - sequence of $32$ bytes, not a bit sequence. + sequence of $32$ bytes, not a \bitSequence. \item Correct an off-by-one in an expression used in the definition of $c$ in \crossref{concretepedersenhash} (this does not change the value of $c$). } %sapling @@ -15745,12 +15801,12 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2020.1.9}{2020-07-05} \begin{itemize} \item Add \crossref{networks}. - \item Acknowledge Jane Lusby and Teor. + \item Acknowledge Jane Lusby and teor. \item Precisely specify the encoding and decoding of \EdSpecific points. \sapling{ \item Correct an error introduced in \historyref{2020.1.8}; ``$-\ZeroJ$'' was incorrectly used when the point $(0, -1)$ on \Jubjub was meant. - \item Precisely specify the conversion from a bit sequence in $\abstJ$. + \item Precisely specify the conversion from a \bitSequence in $\abstJ$. } %sapling \end{itemize} @@ -16097,9 +16153,9 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. Bryan Parno. \item Specify the difficulty adjustment change that occurred on \Testnet at \blockHeight $299188$. - \item Add Eirik Ogilvie-Wigley and Benjamin Winston to acknowledgements. + \item Add Eirik \nh{Ogilvie-Wigley} and Benjamin Winston to acknowledgements. \sapling{ - \item Rename zk-SNARK Parameters sections to be named according to the proving + \item Rename \zkSNARK Parameters sections to be named according to the proving system (\BCTV or \Groth), not the shielded protocol construction (\Sprout or \Sapling). \item In \crossref{networkupgrades}, say when \Sapling activated. @@ -16125,7 +16181,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. to match sapling-crypto. \item Describe $2$-bit window lookup with conditional negation in \crossref{cctpedersenhash}. \item Fix or complete various calculations of constraint costs. - \item Adjust the notation used for scalar multiplication in Appendix A to allow bit sequences + \item Adjust the notation used for scalar multiplication in Appendix A to allow \bitSequences as scalars. } %sapling \end{itemize} @@ -16238,7 +16294,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. how verification depends on \primaryInputs. } %sapling \item Add Charles Rackoff, Rafail Ostrovsky, and Amit Sahai to the acknowledgements - section for their work on zero-knowledge proofs. + section for their work on \zeroKnowledgeProofs. \end{itemize} \historyentry{2018.0-beta-26}{2018-08-05} @@ -16318,8 +16374,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Clarify attribution of the \Zcash protocol design. \item Acknowledge Alex Biryukov and Dmitry Khovratovich as the designers of \Equihash. \item Acknowledge Shafi Goldwasser, Silvio Micali, Oded Goldreich, Rosario Gennaro, Bryan Parno, Jon Howell, - Craig Gentry, Mariana Raykova, and Jens Groth for their work on zero-knowledge proving systems. - \item Acknowledge Tomas Sander and Amnon Ta–Shma for \cite{ST1999}. + Craig Gentry, Mariana Raykova, and Jens Groth for their work on \zeroKnowledgeProvingSystems. + \item Acknowledge Tomas Sander and Amnon \nh{Ta-Shma} for \cite{ST1999}. \item Acknowledge Kudelski Security's audit. \sapling{ \item Use the more precise subgroup types $\SubgroupG{}$ and $\SubgroupJ$ in preference to @@ -16332,7 +16388,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. field of an \outputDescription{} must be canonical encodings. \item Enforce that $\EphemeralPrivate$ in $\outCiphertext$ is a canonical encoding. \item Add consensus rules that $\cv$ in a \spendDescription, and $\cv$ and $\EphemeralPublic$ in an - \outputDescription, are not of small order. Exclude $0$ from the range of $\EphemeralPrivate$ + \outputDescription, are not of \smallOrder. Exclude $0$ from the range of $\EphemeralPrivate$ when encrypting \Sapling notes. \item Add a consensus rule that $\valueBalance{Sapling}$ is in the range $\range{-\MAXMONEY}{\MAXMONEY}$. \item Enforce stronger constraints on the types of key components $\DiversifiedTransmitPublic$, @@ -16402,7 +16458,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Change the notation $\RedDSAHash^{\star}$ to $\RedDSAHashToScalar$ in \crossref{concreteredjubjub}, to avoid confusion with the $^{\Repr}$ convention for representations of group elements. \item $\cmuField$ encodes only the $u$-coordinate of the \noteCommitment, not the full curve point. - \item $\AuthSignRandomizedPublic$ is checked to be not of small order outside the \spendStatement, + \item $\AuthSignRandomizedPublic$ is checked to be not of \smallOrder outside the \spendStatement, not in the \spendStatement. \item Change terminology describing constraint systems. } %sapling @@ -16446,10 +16502,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Explicitly note that outputs from \coinbaseTransactions include \foundersReward outputs. \item The point represented by $\EdDSAReprR{}$ in an \EdSpecific signature is checked - to not be of small order; this is not the same as checking that it is of - prime order $\ell$. + to not be of \smallOrder; this is not the same as checking that it is of + \primeOrder $\ell$. \item Specify support for \cite{BIP-111} (the \texttt{NODE\_BLOOM} service bit) - in peer-to-peer network protocol version $170004$. + in \peerToPeerProtocol version $170004$. \item Give references \cite{Vercauter2009} and \cite{AKLGL2010} for the optimal ate pairing. \item Give references for BLS \cite{BLS2002} and BN \cite{BN2005} curves. \item Define $\KADerivePublic{Sprout}$ for $\KASproutCurve$. @@ -16494,7 +16550,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Updates to \Sapling construction, changing how the \nullifier is computed and separating it from the \authRandomizedValidatingKey ($\AuthSignRandomizedPublic$). - \item Clarify conversions between bit and byte sequences for + \item Clarify conversions between \bitSequences and \byteSequences for $\SpendingKey$, $\reprJ\Of{\AuthSignPublic}$, and $\reprJ\Of{\NullifierKey}$. } %sapling \item Change the \Makefile to avoid multiple reloads in PDF readers while @@ -16531,7 +16587,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item delete not-all-one component which is no longer needed \item factor out xor into its own component \item specify [un]packing more precisely; separate it from boolean constraints - \item optimize checking for non-small order + \item optimize checking for non-\smallOrder \item notation in variable-base multiplication algorithm. \end{itemize} } @@ -16631,7 +16687,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. collision with $\KASproutCurve$ scalar ``clamping''. \item Change uses of the term \term{full node} to \fullValidator. A \defining{\term{full node}} by definition participates in the - peer-to-peer network, whereas a \fullValidator just needs a copy + \peerToPeerNetwork, whereas a \fullValidator just needs a copy of the \blockChain from somewhere. The latter is what was meant. \sapling{ \item Add an explanation of how \Sapling prevents Faerie Gold and @@ -16721,7 +16777,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2017.0-beta-2.5}{2017-03-07} \begin{itemize} - \item Clarify the consensus rule preventing double-spends. + \item Clarify the consensus rule preventing \doubleSpends. \item Clarify what a \noteCommitment opens to in \crossref{crprf}. \item Correct the order of arguments to $\CommitAlg$ in \crossref{concretesproutnotecommit}. \item Correct a statement about indistinguishability of \joinSplitDescriptions. @@ -16849,7 +16905,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Update the section on encoding of \transparentAddresses. (The precise prefixes are not decided yet.) \item Clarify why $\BlakeTwob{\ell}$ is different from truncated $\BlakeTwob{512}$. - \item Clarify a note about SU-CMA security for signatures. + \item Clarify a note about \nh{SU-CMA} security for signatures. \item Add a note about $\PRFnf{Sprout}{}$ corresponding to $\PRFsn{}$ in \Zerocash. \item Add a paragraph about key length in \crossref{inbandrationale}. \item Add acknowledgements for John Tromp, Paige Peterson, Maureen Walsh, @@ -16860,7 +16916,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \item Update the \foundersReward address list. - \item Add some clarifications based on Eli Ben-Sasson's review. + \item Add some clarifications based on Eli \nh{Ben-Sasson}'s review. \end{itemize} \historyentry{2016.0-beta-1.4}{2016-09-19} @@ -16905,7 +16961,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Major reorganization to separate the abstract cryptographic protocol from the algorithm instantiations. \item Add type declarations. - \item Add a ``High-level Overview'' section. + \item Add a ``\nh{High-level} Overview'' section. \item Add a section specifying the \zeroKnowledgeProvingSystem and the encoding of proofs. Change the encoding of points in proofs to follow IEEE Std 1363[a]. @@ -16920,7 +16976,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. match the implemented protocol. \item Add a consensus rule about the ranges of $\vpubOld$ and $\vpubNew$. \item Clarify cryptographic security requirements and added definitions - relating to the in-band secret distribution. + relating to the \inBand secret distribution. \item Add various citations: the ``Fixing Vulnerabilities in the Zcash Protocol'' and ``Why Equihash?'' blog posts, several crypto papers for security definitions, the \Bitcoin whitepaper, the \CryptoNote @@ -17045,9 +17101,9 @@ A point $P$ is normally represented by two $\GF{\ParamS{r}}$ variables, which we name as $(P^u, P^{\spv})$ for an \affineCtEdwards point, for instance. The implementations of scalar multiplication require the scalar to be represented -as a bit sequence. We therefore allow the notation $\scalarmult{k\Repr}{P}$ meaning +as a \bitSequence. We therefore allow the notation $\scalarmult{k\Repr}{P}$ meaning $\scalarmult{\LEBStoIPOf{\length(k\Repr)}{k\Repr}}{P}$. There will be no ambiguity -because variables representing bit sequences are named with a $\Repr$ suffix. +because variables representing \bitSequences are named with a $\Repr$ suffix. \introlist The \defining{\MontgomeryCurve} $\MontCurve$ has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = 1$. @@ -17082,7 +17138,7 @@ ctEdwards coordinates: \item $\CompressedCtEdwardsJubjub := (\tilde{u} \typecolon \bit) \times (\varv \typecolon \GF{\ParamS{r}})$ \end{formulae} \vspace{-1.5ex} -See \crossref{jubjub} for how this type is represented as a byte sequence in +See \crossref{jubjub} for how this type is represented as a \byteSequence in external encodings. \vspace{2ex} @@ -17328,7 +17384,7 @@ constrains $a_i$ to be $0$ if $\Pi_{i+1} = 1$, otherwise it constrains $a_i \in So all of $a_{\barerange{0}{n-1}}$ are at least boolean-constrained. To prove the rest of the theorem we proceed by induction on decreasing $m$, -i.e.\ taking successively longer prefixes of the big-endian binary representations +i.e.\ taking successively longer prefixes of the \bigEndian binary representations of $a$ and $c$. Base case $m = n-1$: since $c_{n-1} = 1$, the constraint system has @@ -17647,7 +17703,7 @@ $(u_1, \varv_1) + (u_2, \varv_2) = (u_3, \varv_3)$ are: \end{formulae} \introlist -We use an optimized implementation found by Daira Emma Hopwood making use of an +We use an optimized implementation found by \nh{Daira-Emma} Hopwood making use of an observation by Bernstein and Lange in \cite[last paragraph of section 4.5.2]{BL2017}: \begin{formulae} @@ -17692,11 +17748,11 @@ $(u, \varv) = (u_1, \varv_1) = (u_2, \varv_2)$ and observing that $u \mult \varv \lsubsubsubsection{Affine-ctEdwards nonsmall-order check}{cctednonsmallorder} In order to avoid small-subgroup attacks, we check that certain points used in the -circuit are not of small order. In practice the \Sapling circuit uses this +circuit are not of \smallOrder. In practice the \Sapling circuit uses this in combination with a check that the coordinates are on the curve (\crossref{cctedvalidate}), so we combine the two operations. -The \jubjubCurve has a large prime-order subgroup with a cofactor of $8$. +The \jubjubCurve has a large \primeOrderSubgroup with a cofactor of $8$. To check for a point $P$ of order $8$ or less, the \Sapling circuit doubles three times (as in \crossref{cctedarithmetic}) and checks that the resulting $u$-coordinate is not $0$ (as in \crossref{cctnonzero}). @@ -17708,7 +17764,7 @@ only $\ZeroJ$. The total cost, including the curve check, is $4 + 3 \mult 5 + 1 = 20$ constraints. -\pnote{This \emph{does not} ensure that the point is in the prime-order subgroup.} +\pnote{This \emph{does not} ensure that the point is in the \primeOrderSubgroup.} \begin{nnotes} \item It would have been sufficient to do two doublings rather than three, because @@ -17759,8 +17815,8 @@ $s = 4 \smult s_2 + 2 \smult s_1 + s_0$, we use: - \spv_2 \smult s_1 \plus \spv_4 \smult s\suband - \spv_4 \smult s_2 - \spv_6 \smult s\suband}$ \end{formulae} -For a full-length ($252$-bit) scalar this costs $3$ constraints for each of $84$ window lookups, -plus $6$ constraints for each of $83$ ctEdwards additions (as in \crossref{cctedarithmetic}), for +For a \nh{full-length ($252$-bit)} scalar this costs $3$ constraints for each of $84$ window lookups, +plus $6$ constraints for each of $83$ \xCtEdwards additions (as in \crossref{cctedarithmetic}), for a total of $750$ constraints. Fixed-base scalar multiplication is also used in two places with shorter scalars: @@ -17829,8 +17885,8 @@ Given $k = \ssum{i=0}{250} k_i \smult 2^i$, we calculate $R = \scalarmult{k}{B}$ \item let $R = \Acc_{250}$. \end{algorithm} -This costs $5$ constraints for each of $250$ ctEdwards doublings, $6$ constraints for each -of $250$ ctEdwards additions, and $2$ constraints for each of $251$ point selections, +This costs $5$ constraints for each of $250$ \xCtEdwards doublings, $6$ constraints for each +of $250$ \xCtEdwards additions, and $2$ constraints for each of $251$ point selections, for a total of $3252$ constraints. \nnote{ @@ -17895,7 +17951,7 @@ are defined as in \crossref{concretepedersenhash}. \vspace{1ex} We have to prove that: \begin{itemize} - \item the Montgomery-to-ctEdwards conversions can be implemented without + \item the Montgomery-to-\xCtEdwards conversions can be implemented without exceptional cases; \item the \distinctXCriterion is met for all Montgomery additions within a segment. @@ -17906,10 +17962,10 @@ all indices of addition inputs are in the range $\bigrangenozero{-\frac{\ParamJ{r}-1}{2}}{\frac{\ParamJ{r}-1}{2}}$. Because the $\PedersenGen(D, j)$ (which are outputs of $\GroupJHash{}$) -are all of prime order, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$, +are all of \primeOrder, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$, it is guaranteed that all of the terms $\scalarmult{\PedersenEncode{M_j}}{\PedersenGen(D, j)}$ -to be converted to ctEdwards form are of prime order. +to be converted to \xCtEdwards form are of \primeOrder. From \theoremref{thmconversiontoedwardsnoexcept}, we can infer that the conversions will not encounter exceptional cases. @@ -18027,8 +18083,8 @@ The cost is then: \begin{itemize} \item $2 \smult c$ constraints for the lookups; \item $3 \smult (c-n)$ constraints for incomplete additions on the \MontgomeryCurve; - \item $2 \smult n$ constraints for Montgomery-to-ctEdwards conversions; - \item $6 \smult (n-1)$ constraints for ctEdwards additions; + \item $2 \smult n$ constraints for Montgomery-to-\xCtEdwards conversions; + \item $6 \smult (n-1)$ constraints for \xCtEdwards additions; \end{itemize} \vspace{-1ex} @@ -18065,7 +18121,7 @@ We define $\MixingPedersenHash \typecolon \range{0}{\ParamJ{r}-1} \end{formulae} This costs $92$ constraints for a scalar multiplication -(\crossref{cctfixedscalarmult}), and $6$ constraints for a ctEdwards addition +(\crossref{cctfixedscalarmult}), and $6$ constraints for a \xCtEdwards addition (\crossref{cctedarithmetic}), for a total of $98$ constraints. @@ -18089,7 +18145,7 @@ that is, it is \emph{not} necessary to ensure that the left or right inputs to t hash represent integers in the range $\range{0}{\ParamS{r}-1}$. Since the root of the Merkle tree is calculated outside the circuit using the canonical representations, and since the \xPedersenHashes are \collisionResistant -on arbitrary bit-sequence inputs, an attempt by an adversarial prover to use a +on arbitrary \bitSequenceAdjective inputs, an attempt by an adversarial prover to use a \nonCanonicalFieldElement input would result in the wrong root being calculated, and the overall path check would fail. @@ -18122,7 +18178,7 @@ This can be implemented in: $\ell = 6 + \length(s)$ bits, where $c = \ceiling{\hfrac{\ell}{3}}$ and $n = \ceiling{\hfrac{\ell}{3 \mult 63}}$; \item $750$ constraints for the fixed-base scalar multiplication; - \item $6$ constraints for the final ctEdwards addition. + \item $6$ constraints for the final \xCtEdwards addition. \end{itemize} When $\WindowedPedersenCommit{}$ is used to instantiate $\NoteCommitAlg{Sapling}$, @@ -18158,7 +18214,7 @@ $\ValueCommitAlg{}$ can be implemented in: \begin{itemize} \item $750$ constraints for the $252$-bit fixed-base multiplication by $\ValueCommitRand$; \item $191$ constraints for the $64$-bit fixed-base multiplication by $\Value$; - \item $6$ constraints for the ctEdwards addition + \item $6$ constraints for the \xCtEdwards addition \end{itemize} \vspace{-1.5ex} for a total cost of $947$ constraints. This does not include the cost to boolean-constrain @@ -18249,7 +18305,7 @@ Define $\BlakeTwos{256} \typecolon (p \typecolon \byteseq{8}) \times (x \typecol \item return $\LEBStoOSPOf{256}{\concatbits\Of{\listcomp{\ItoLEBSPOf{32}{h_i \xor v_i \xor v_{i+8}} \for i \from 0 \upto 7}}}$ \end{formulae} -In practice the message and output will be expressed as bit sequences. In the \Sapling +In practice the message and output will be expressed as \bitSequences. In the \Sapling circuit, the personalization string will be constant for each use. Each 32-bit exclusive-or is implemented in $32$ constraints, one for each bit position @@ -18397,7 +18453,7 @@ Check & Implements & \heading{Cost} & Reference \\ $\AuthSignPublic$ is on the curve \small\todo{FIXME also decompressed below} & $\AuthSignPublic \typecolon \SpendAuthSigPublic{Sapling}$ & 4 & \shortcrossref{cctedvalidate} \\ \hline - $\AuthSignPublic$ is not small order + $\AuthSignPublic$ is not \smallOrderAdjective & \snarkref{Small order checks}{spendnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\AuthSignRandomizerRepr \typecolon \bitseq{\ScalarLength{Sapling}}$ @@ -18431,7 +18487,7 @@ Check & Implements & \heading{Cost} & Reference \\ $\DiversifiedTransmitBase$ is on the curve & $\DiversifiedTransmitBase \typecolon \GroupJ$ & 4 & \shortcrossref{cctedvalidate} \\ \hline - $\DiversifiedTransmitBase$ is not small order + $\DiversifiedTransmitBase$ is not \smallOrderAdjective & \snarkref{Small order checks}{spendnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\DiversifiedTransmitPublic = \scalarmult{\InViewingKeyRepr}{\DiversifiedTransmitBase}$ @@ -18488,12 +18544,12 @@ Check & Implements & \heading{Cost} & Reference \\ \end{center} \vspace{1ex} -$\dagger$ This is implemented by taking the output of $\BlakeTwos{256}$ as a bit sequence and dropping the most -significant $5$~bits, not by converting to an integer and back to a bit sequence as literally specified. +$\dagger$ This is implemented by taking the output of $\BlakeTwos{256}$ as a \bitSequence and dropping the most +significant $5$~bits, not by converting to an integer and back to a \bitSequence as literally specified. \pnote{The implementation represents $\AuthSignRandomizerRepr$, $\AuthProvePrivateRepr$, $\InViewingKeyRepr$, -$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as bit sequences rather than integers. It -represents $\nf$ as a bit sequence rather than a byte sequence.} +$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as \bitSequences rather than integers. It +represents $\nf$ as a \bitSequence rather than a \byteSequence.} \introsection @@ -18569,7 +18625,7 @@ Check & Implements & \heading{Cost} & Reference \\ $\DiversifiedTransmitBaseRepr = \reprJ(\DiversifiedTransmitBase \typecolon \GroupJ)$ & \snarkref{Note commitment integrity}{outputnotecommitmentintegrity} & 392 & \shortcrossref{ccteddecompressvalidate} \\ \hline - $\DiversifiedTransmitBase$ is not small order + $\DiversifiedTransmitBase$ is not \smallOrderAdjective & \snarkref{Small order checks}{outputnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\EphemeralPrivateRepr \typecolon \bitseq{\ScalarLength{Sapling}}$ @@ -18598,7 +18654,7 @@ Check & Implements & \heading{Cost} & Reference \\ \end{center} \pnote{The implementation represents $\EphemeralPrivateRepr$, $\DiversifiedTransmitPublicRepr$, -$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as bit sequences rather than integers.} +$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as \bitSequences rather than integers.} \lsection{Batching Optimizations}{batching} diff --git a/protocol/sapling.pdf b/protocol/sapling.pdf index c65d927d..8304c988 100644 Binary files a/protocol/sapling.pdf and b/protocol/sapling.pdf differ diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 650b6f52..3efa7d4d 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -1,6 +1,6 @@ @misc{BCGGMTV2014, presort={BCGGMTV2014}, - author={Eli Ben-Sasson and Alessandro Chiesa and Christina Garman and Matthew Green and Ian Miers and Eran Tromer and Madars Virza}, + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Christina Garman and Matthew Green and Ian Miers and Eran Tromer and Madars Virza}, title={Zerocash: Decentralized {A}nonymous {P}ayments from {B}itcoin (extended version)}, url={https://eprint.iacr.org/2014/349}, urldate={2021-04-05}, @@ -12,18 +12,18 @@ pages 459--474; IEEE, 2014.} @misc{BCTV2014a, presort={BCTV2014a}, - author={Eli Ben-Sasson and Alessandro Chiesa and Eran Tromer and Madars Virza}, - title={Succinct\, {N}on\hyp {I}nteractive\, {Z}ero\, {K}nowledge\, for\, a\, von\, {N}eumann\, {A}rchitecture}, + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Eran Tromer and Madars Virza}, + title={Succinct {N}on-{I}nteractive {Z}ero {K}nowledge for a von~{N}eumann {A}rchitecture}, url={https://eprint.iacr.org/2013/879}, urldate={2019-02-08}, - howpublished={Cryptology\, ePrint\, Archive:\, Report\, 2013/879. + howpublished={Cryptology ePrint Archive: Report 2013/879. Last revised February~5, 2019.} } @misc{BCTV2014a-old, presort={BCTV2014a-old}, - author={Eli Ben-Sasson and Alessandro Chiesa and Eran Tromer and Madars Virza}, - title={Succinct {N}on-{I}nteractive {Z}ero {K}nowledge for a von {N}eumann {A}rchitecture + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Eran Tromer and Madars Virza}, + title={Succinct {N}on-{I}nteractive {Z}ero {K}nowledge for a von~{N}eumann {A}rchitecture ({M}ay~19, 2015 version)}, url={https://eprint.iacr.org/2013/879/20150519:172604}, urldate={2019-02-08}, @@ -61,7 +61,7 @@ Received May~6, 2015.} @misc{BCGTV2013, presort={BCGTV2013}, - author={Eli Ben-Sasson and Alessandro Chiesa and Daniel Genkin and Eran Tromer and Madars Virza}, + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Daniel Genkin and Eran Tromer and Madars Virza}, title={{SNARK}s for {C}: {V}erifying {P}rogram {E}xecutions {S}uccinctly and in {Z}ero {K}nowledge}, url={https://eprint.iacr.org/2013/507}, urldate={2016-08-31}, @@ -85,7 +85,7 @@ Lecture Notes in Computer Science; Springer, 2013.}, @inproceedings{BCTV2014b, presort={BCTV2014b}, - author={Eli Ben-Sasson and Alessandro Chiesa and Eran Tromer and Madars Virza}, + author={Eli {Ben\nbh{}Sasson} and Alessandro Chiesa and Eran Tromer and Madars Virza}, title={Scalable {Z}ero {K}nowledge via {C}ycles of {E}lliptic {C}urves (extended version)}, booktitle={Advances in Cryptology - CRYPTO~2014}, volume={8617}, @@ -191,7 +191,7 @@ Last revised September~3, 2020.} % Capitalized De/Di is correct @inproceedings{DSDCOPS2001, presort={DSDCOPS2001}, - author={Alfredo {De Santis} and Giovanni {Di Crescenzo} and Rafail Ostrovsky and Guiseppe Persiano and Amit Sahai}, + author={Alfredo {De~Santis} and \;Giovanni {Di~Crescenzo} and \;Rafail Ostrovsky and \;Guiseppe Persiano and \;Amit Sahai}, title={Robust {N}on-{I}nteractive {Z}ero {K}nowledge}, booktitle={Advances in Cryptology - CRYPTO~2001. Proceedings of the 21st Annual International Cryptology Conference @@ -304,7 +304,7 @@ Conference on Computer and Communications Security}, booktitle={Public Key Cryptography -- PKC 2006. Proceedings of the 9th International Conference on Theory and Practice in Public-Key Cryptography (New York, NY, USA, April~24--26, 2006)}, - publisher={Springer-Verlag}, + publisher={Springer}, date={2006-02-09}, url={https://cr.yp.to/papers.html#curve25519}, urldate={2021-04-05}, @@ -313,7 +313,7 @@ Proceedings of the 9th International Conference on Theory and Practice in Public @article{BDLSY2012, presort={BDLSY2012}, - author={Daniel Bernstein and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang}, + author={Daniel Bernstein and Niels Duif and Tanja Lange and Peter Schwabe and {Bo\nbh{}Yin} Yang}, title={High-speed high-security signatures}, journal={Journal of Cryptographic Engineering}, volume={2}, @@ -336,14 +336,14 @@ Proceedings of the 9th International Conference on Theory and Practice in Public @inproceedings{deRooij1995, presort={deRooij1995}, - author={Peter {de Rooij}}, + author={Peter {de~Rooij}}, title={Efficient exponentiation using precomputation and vector addition chains}, booktitle={Advances in Cryptology - EUROCRYPT~'94. Proceedings, Workshop on the Theory and Application of Cryptographic Techniques (Perugia, Italy, May~9--12, 1994)}, volume={950}, series={Lecture Notes in Computer Science}, - editor={Alfredo {De Santis}}, + editor={Alfredo {De~Santis}}, pages={389--399}, publisher={Springer}, isbn={978-3-540-60176-0}, @@ -375,7 +375,7 @@ Received March~30, 2017.} @misc{BJLSY2015, presort={BJLSY2015}, - author={Daniel Bernstein and Simon Josefsson and Tanja Lange and Peter Schwabe and Bo-Yin Yang}, + author={Daniel Bernstein and Simon Josefsson and Tanja Lange and Peter Schwabe and {Bo\nbh{}Yin} Yang}, title={{EdDSA} for more curves}, url={https://cr.yp.to/papers.html#eddsa}, urldate={2018-01-22}, @@ -394,7 +394,7 @@ Received March~30, 2017.} @misc{FKMSSS2016, presort={FKMSSS2016}, author={Nils Fleischhacker and Johannes Krupp and Giulio Malavolta and Jonas Schneider and Dominique Schröder and Mark Simkin}, - title={Efficient\; {U}nlinkable\; {S}anitizable\; {S}ignatures\; from\; {S}ignatures\; with\; {R}e\hyp {R}andomizable\; {K}eys}, + title={Efficient\; {U}nlinkable\; {S}anitizable\; {S}ignatures\; from\; {S}ignatures\; with\; {R}e-{R}andomizable\; {K}eys}, url={https://eprint.iacr.org/2015/395}, urldate={2018-03-03}, howpublished={Cryptology ePrint Archive: Report 2012/159. @@ -402,7 +402,7 @@ Last revised February~11, 2016.}, addendum={An extended abstract appeared in \textsl{Public Key Cryptography -- PKC 2016: 19th IACR International Conference on Practice and Theory in Public-Key Cryptography (Taipei, Taiwan, March~6--9, 2016), Proceedings, Part~1};\, -Ed. by Chen-Mou Cheng, Kai-Min Chung, Giuseppe Persiano, and Bo-Yin Yang;\, +Ed. by {Chen\nbh{}Mou} Cheng, {Kai\nbh{}Min} Chung, Giuseppe Persiano, and {Bo\nbh{}Yin} Yang;\, Vol.~9614, Lecture Notes in Computer Science, pages 301--330; Springer, 2016; ISBN 978-3-662-49384-7.} } @@ -410,7 +410,7 @@ Springer, 2016; ISBN 978-3-662-49384-7.} @misc{DS2016, presort={DS2016}, author={David Derler and Daniel Slamanig}, - title={Key\hyp {H}omomorphic {S}ignatures and {A}pplications to {M}ultiparty {S}ignatures and {N}on\hyp {I}nteractive {Z}ero\hyp {K}nowledge}, + title={Key-{H}omomorphic {S}ignatures and {A}pplications to {M}ultiparty {S}ignatures and {N}on-{I}nteractive {Z}ero-{K}nowledge}, url={https://eprint.iacr.org/2016/792}, urldate={2018-04-09}, howpublished={Cryptology ePrint Archive: Report 2016/792. @@ -524,8 +524,7 @@ Received October~20, 2020.} @misc{ANWW2013, presort={ANWW2013}, - author={Jean-Philippe Aumasson and \;Samuel Neves and \;Zooko Wilcox-O'Hearn and -\;Christian Winnerlein}, + author={{Jean\nbh{}Philippe} Aumasson and Samuel Neves and Zooko Wilcox and Christian Winnerlein}, date={2013-01-29}, title={{BLAKE2}: simpler, smaller, fast as {MD5}}, url={https://blake2.net/#sp}, @@ -553,7 +552,7 @@ Last updated December~16, 2020.} @misc{Poseidon-Zc1.1, presort={Poseidon-Zc1.1}, - author={Lorenzo Grassi and Dmitry Khovratovich and Christian Rechberger and Arnab Roy and Markus Schofnegger and Daira Emma Hopwood}, + author={Lorenzo Grassi and Dmitry Khovratovich and Christian Rechberger and Arnab Roy and Markus Schofnegger and {Daira\nbh{}Emma} Hopwood}, title={Poseidon reference implementation, Zcash fork, Version 1.1}, date={2021-07-28}, url={https://github.com/daira/pasta-hadeshash}, @@ -562,7 +561,7 @@ Last updated December~16, 2020.} @misc{BDPA2007, presort={BDPA2007}, - author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}}, + author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van~Assche}}, title={Sponge functions}, url={https://keccak.team/files/SpongeFunctions.pdf}, urldate={2022-08-31}, @@ -572,7 +571,7 @@ as part of the Hash Algorithm Requirements and Evaluation Criteria for the SHA-3 @misc{BDPA2011, presort={BDPA2011}, - author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}}, + 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}, @@ -581,7 +580,7 @@ as part of the Hash Algorithm Requirements and Evaluation Criteria for the SHA-3 @misc{ADMA2015, presort={ADMA2015}, - author={Elena Andreeva and Joan Daemen and Bart Mennink and Gilles {Van Assche}}, + 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}, @@ -649,7 +648,7 @@ 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}, +María {Naya\nbh{}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}, @@ -684,7 +683,7 @@ Received May~21, 2016.} @misc{RFC-7693, presort={RFC-7693}, - author={Markku-Juhani Saarinen (ed.)}, + author={{Markku\nbh{}Juhani} Saarinen (ed.) and {Jean\nbh{}Philippe} Aumasson}, title={Request for {C}omments 7693: {T}he {BLAKE2} {C}ryptographic {H}ash and {M}essage {A}uthentication {C}ode ({MAC})}, howpublished={Internet Engineering Task Force (IETF)}, @@ -718,7 +717,7 @@ Received May~21, 2016.} @misc{ID-hashtocurve, presort={ID-hashtocurve}, - author={Armando Faz-Hernández and Sam Scott and Nick Sullivan and Riad Wahby and Christopher Wood}, + author={Armando {Faz\nbh{}Hernández} and Sam Scott and Nick Sullivan and Riad Wahby and Christopher Wood}, title={Internet {D}raft: {H}ashing to Elliptic Curves, version 10}, howpublished={Internet Research Task Force (IRTF) Crypto Forum Research Group (CFRG). Work in progress. Last revised December~22, 2020.}, url={https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html}, @@ -736,7 +735,7 @@ Received May~21, 2016.} @inproceedings{BCIMRT2010, presort={BCIMRT2010}, - author={Eric Brier and Jean-Sébastien Coron and Thomas Icart and David Madore and Hugues Randriam and Mehdi Tibouchi}, + author={Eric Brier and {Jean\nbh{}Sébastien} Coron and Thomas Icart and David Madore and Hugues Randriam and Mehdi Tibouchi}, title={Efficient Indifferentiable Hashing into Ordinary Elliptic Curves}, booktitle={Advances in Cryptology - CRYPTO~2010. Proceedings of the 30th Annual International Cryptology Conference @@ -755,12 +754,12 @@ Proceedings of the 30th Annual International Cryptology Conference @inproceedings{SvdW2006, presort={SvdW2006}, - author={Andrew Shallue and Christiaan E. van de Woestijne}, + author={Andrew Shallue and Christiaan E. {van~de~Woestijne}}, title={Construction of Rational Points on Elliptic Curves over Finite Fields}, - booktitle={Algorithmic Number Theory: 7th International Symposium, ANTS-VII (Berlin, Germany, July~23--28, 2006)}, + booktitle={Algorithmic Number Theory: 7th International Symposium, {ANTS-VII} (Berlin, Germany, July~23--28, 2006)}, volume={4076}, series={Lecture Notes in Computer Science}, - editor={F. Hess and S. Pauli and M. Pohst}, + editor={Florian Hess and Sebastian Pauli and Michael Pohst}, pages={510--524}, year={2006}, publisher={Springer}, @@ -786,7 +785,7 @@ Proceedings of the 30th Annual International Cryptology Conference @article{FFSTV2013, presort={FFSTV2013}, - author={Reza Farashahi and Pierre-Alain Fouque and Igor Shparlinski and Mehdi Tibouchi and J. Felipe Voloch}, + author={Reza Farashahi and {Pierre\nbh{}Alain} Fouque and Igor Shparlinski and Mehdi Tibouchi and J. Felipe Voloch}, title={Indifferentiable deterministic hashing to elliptic and hyperelliptic curves}, journal={Mathematics of Computation}, volume={82}, @@ -802,14 +801,14 @@ Proceedings of the 30th Annual International Cryptology Conference author={Taechan Kim and Mehdi Tibouchi}, title={Improved Elliptic Curve Hashing and Point Representation}, booktitle={Proceedings of WCC2015 - 9th International Workshop on Coding and Cryptography (Paris, France, April 2015)}, - editor={Anne Canteaut and Gaëtan Leurent and Maria Naya-Plasencia}, + editor={Anne Canteaut and Gaëtan Leurent and Maria {Naya\nbh{}Plasencia}}, url={https://hal.inria.fr/hal-01275711}, urldate={2021-01-28} } @article{BGHOZ2013, presort={BGHOZ2013}, - author={Gilles Barthe and Benjamin Grégoire and Sylvain Heraud and Frederico Olmedo and Santiago Zanella-Béguelin}, + author={Gilles\; Barthe and \;\;Benjamin\; Grégoire and \;\;Sylvain\; Heraud and \;\;Frederico\; Olmedo and \;\;Santiago {Zanella\nbh{}Béguelin}}, title={Verified indifferentiable hashing into elliptic curves}, journal={Journal of Computer Security, Security and Trust Principles}, volume={21}, @@ -896,7 +895,7 @@ L. Hernández Encinas and C. Sánchez Ávila}, @misc{ABR1999, presort={ABR1999}, author={Michel Abdalla and Mihir Bellare and Phillip Rogaway}, - title={{DHAES}: {A}n {E}ncryption {S}cheme {B}ased on the {D}iffie-{H}ellman {P}roblem}, + title={{DHAES}: {A}n {E}ncryption {S}cheme {B}ased on the {D}iffie--{H}ellman {P}roblem}, url={https://eprint.iacr.org/1999/007}, urldate={2016-08-21}, date={1998-09}, @@ -905,7 +904,7 @@ L. Hernández Encinas and C. Sánchez Ávila}, @misc{DGKM2011, presort={DGKM2011}, - author={Dana Dachman-Soled and Rosario Gennaro and Hugo Krawczyk and Tal Malkin}, + author={Dana {Dachman\nbh{}Soled} and Rosario Gennaro and Hugo Krawczyk and Tal Malkin}, title={Computational {E}xtractors and {P}seudorandomness}, url={https://eprint.iacr.org/2011/708}, urldate={2016-09-02}, @@ -934,7 +933,7 @@ Last revised February~5, 2018.} @misc{vanSaberh2014, presort={vanSaberh2014}, - author={Nicolas {van Saberhagen}}, + author={Nicolas {van~Saberhagen}}, title={CryptoNote v 2.0}, note={Date disputed.}, url={https://bytecoin.org/old/whitepaper.pdf}, @@ -952,7 +951,7 @@ Last revised February~5, 2018.} @misc{Dalek-notes, presort={Dalek-notes}, - author={Cathie Yun and Henry {de Valence} and Oleg Andreev and Dimitris Apostolou}, + author={Cathie Yun and Henry {de~Valence} and Oleg Andreev and Dimitris Apostolou}, title={Dalek bulletproofs notes, module r1cs\_proof}, url={https://doc-internal.dalek.rs/bulletproofs/notes/r1cs_proof/index.html}, urldate={2021-04-07} @@ -1170,8 +1169,8 @@ Last revised February~5, 2018.} @misc{BIP-68, presort={BIP-0068}, - author={Mark Friedenbach and BtcDrak and Nicolas Dorier and kinoshitajona}, - title={Relative lock-time using consensus\hyp enforced sequence numbers}, + author={Mark\; Friedenbach and \;BtcDrak and \;Nicolas\; Dorier and \;kinoshitajona}, + title={\;Relative\, lock-time\, using consensus-enforced sequence numbers}, howpublished={Bitcoin Improvement Proposal 68. Last revised November~21, 2015}, url={https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki}, urldate={2020-07-13} @@ -1206,7 +1205,7 @@ Last revised February~5, 2018.} @misc{ZIP-32, presort={ZIP-0032}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Shielded Hierarchical Deterministic Wallets}, howpublished={Zcash Improvement Proposal 32.}, url={https://zips.z.cash/zip-0032}, @@ -1215,14 +1214,14 @@ Last revised February~5, 2018.} @misc{ZIP-76, presort={ZIP-0076}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Transaction Signature Validation before {O}verwinter}, howpublished={Zcash Improvement Proposal 76 (in progress).}, } @misc{ZIP-143, presort={ZIP-0143}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Transaction Signature Validation for {O}verwinter}, howpublished={Zcash Improvement Proposal 143. Created December~27, 2017.}, url={https://zips.z.cash/zip-0143}, @@ -1231,7 +1230,7 @@ Last revised February~5, 2018.} @misc{ZIP-173, presort={ZIP-0173}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Bech32 Format}, howpublished={Zcash Improvement Proposal 173. Created June~13, 2018.}, url={https://zips.z.cash/zip-0173}, @@ -1249,7 +1248,7 @@ Last revised February~5, 2018.} @misc{ZIP-201, presort={ZIP-0201}, - author={Simon Liu}, + author={Simon Liu and {Daira\nbh{}Emma} Hopwood}, title={Network Peer Management for {O}verwinter}, howpublished={Zcash Improvement Proposal 201. Created January~15, 2018.}, url={https://zips.z.cash/zip-0201}, @@ -1258,7 +1257,7 @@ Last revised February~5, 2018.} @misc{ZIP-202, presort={ZIP-0202}, - author={Simon Liu}, + author={Simon Liu and {Daira\nbh{}Emma} Hopwood}, title={Version 3 Transaction Format for {O}verwinter}, howpublished={Zcash Improvement Proposal 202. Created January~10, 2018.}, url={https://zips.z.cash/zip-0202}, @@ -1267,7 +1266,7 @@ Last revised February~5, 2018.} @misc{ZIP-203, presort={ZIP-0203}, - author={Jay Graber}, + author={Jay Graber and {Daira\nbh{}Emma} Hopwood}, title={Transaction Expiry}, howpublished={Zcash Improvement Proposal 203. Created January~9, 2018.}, url={https://zips.z.cash/zip-0203}, @@ -1276,7 +1275,7 @@ Last revised February~5, 2018.} @misc{ZIP-205, presort={ZIP-0205}, - author={Daira Emma Hopwood}, + author={Simon Liu and {Daira\nbh{}Emma} Hopwood}, title={Deployment of the {S}apling Network Upgrade}, howpublished={Zcash Improvement Proposal 205. Created October~8, 2018.}, url={https://zips.z.cash/zip-0205}, @@ -1285,7 +1284,7 @@ Last revised February~5, 2018.} @misc{ZIP-206, presort={ZIP-0206}, - author={Daira Emma Hopwood}, + author={Simon Liu and {Daira\nbh{}Emma} Hopwood}, title={Deployment of the {B}lossom Network Upgrade}, howpublished={Zcash Improvement Proposal 206. Created July~29, 2019.}, url={https://zips.z.cash/zip-0206}, @@ -1294,7 +1293,7 @@ Last revised February~5, 2018.} @misc{ZIP-207, presort={ZIP-0207}, - author={Jack Grigg}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Funding Streams}, howpublished={Zcash Improvement Proposal 207. Created January~4, 2019.}, url={https://zips.z.cash/zip-0207}, @@ -1303,7 +1302,7 @@ Last revised February~5, 2018.} @misc{ZIP-208, presort={ZIP-0208}, - author={Simon Liu and Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood and Simon Liu}, title={Shorter Block Target Spacing}, howpublished={Zcash Improvement Proposal 208. Created January~10, 2019.}, url={https://zips.z.cash/zip-0208}, @@ -1312,7 +1311,7 @@ Last revised February~5, 2018.} @misc{ZIP-209, presort={ZIP-0209}, - author={Sean Bowe}, + author={Sean Bowe and {Daira\nbh{}Emma} Hopwood}, title={Prohibit Negative Shielded Value Pool Balances}, howpublished={Zcash Improvement Proposal 209. Created February~25, 2019.}, url={https://zips.z.cash/zip-0209}, @@ -1321,7 +1320,7 @@ Last revised February~5, 2018.} @misc{ZIP-211, presort={ZIP-0211}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Disabling Addition of New Value to the {S}prout Value Pool}, howpublished={Zcash Improvement Proposal 211. Created March~29, 2019.}, url={https://zips.z.cash/zip-0211}, @@ -1348,7 +1347,7 @@ Last revised February~5, 2018.} @misc{ZIP-214, presort={ZIP-0214}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Consensus rules for a {Z}cash Development Fund}, howpublished={Zcash Improvement Proposal 214. Created February~28, 2020.}, url={https://zips.z.cash/zip-0214}, @@ -1357,7 +1356,7 @@ Last revised February~5, 2018.} @misc{ZIP-215, presort={ZIP-0215}, - author={Henry de Valance}, + author={Henry {de~Valence}}, title={Explicitly Defining and Modifying {Ed25519} Validation Rules}, howpublished={Zcash Improvement Proposal 215. Created April~27, 2020.}, url={https://zips.z.cash/zip-0215}, @@ -1366,7 +1365,7 @@ Last revised February~5, 2018.} @misc{ZIP-216, presort={ZIP-0216}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Require Canonical Point Encodings}, howpublished={Zcash Improvement Proposal 216. Created February~11, 2021.}, url={https://zips.z.cash/zip-0216}, @@ -1375,7 +1374,7 @@ Last revised February~5, 2018.} @misc{ZIP-221, presort={ZIP-0221}, - author={Jack Grigg}, + author={{Ying~Tong} Lai and James Prestwich and Georgios Konstantopoulos and Jack Grigg}, title={{FlyClient} - Consensus-Layer Changes}, howpublished={Zcash Improvement Proposal 221. Created March~30, 2019.}, url={https://zips.z.cash/zip-0221}, @@ -1393,7 +1392,7 @@ Last revised February~5, 2018.} @misc{ZIP-224, presort={ZIP-0224}, - author={Daira Emma Hopwood and Jack Grigg and Sean Bowe and Kris Nuttycombe and Ying Tong Lai}, + author={{Daira\nbh{}Emma} Hopwood and Jack Grigg and Sean Bowe and Kris Nuttycombe and {Ying~Tong} Lai}, title={Orchard Shielded Protocol}, howpublished={Zcash Improvement Proposal 224. Created February~27, 2021.}, url={https://zips.z.cash/zip-0225}, @@ -1402,7 +1401,7 @@ Last revised February~5, 2018.} @misc{ZIP-225, presort={ZIP-0225}, - author={Daira Emma Hopwood and Jack Grigg and Sean Bowe and Kris Nuttycombe and Ying Tong Lai}, + author={{Daira\nbh{}Emma} Hopwood and Jack Grigg and Sean Bowe and Kris Nuttycombe and {Ying~Tong} Lai}, title={Version 5 Transaction Format}, howpublished={Zcash Improvement Proposal 225. Created February~28, 2021.}, url={https://zips.z.cash/zip-0225}, @@ -1411,7 +1410,7 @@ Last revised February~5, 2018.} @misc{ZIP-239, presort={ZIP-0239}, - author={Daira Emma Hopwood and Jack Grigg}, + author={{Daira\nbh{}Emma} Hopwood and Jack Grigg}, title={Relay of Version 5 Transactions}, howpublished={Zcash Improvement Proposal 239. Created May~29, 2021.}, url={https://zips.z.cash/zip-0239}, @@ -1420,7 +1419,7 @@ Last revised February~5, 2018.} @misc{ZIP-243, presort={ZIP-0243}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={Transaction Signature Validation for {S}apling}, howpublished={Zcash Improvement Proposal 243. Created April~10, 2018.}, url={https://zips.z.cash/zip-0243}, @@ -1429,7 +1428,7 @@ Last revised February~5, 2018.} @misc{ZIP-244, presort={ZIP-0244}, - author={Kris Nuttycombe and Daira Emma Hopwood}, + author={Kris Nuttycombe and {Daira\nbh{}Emma} Hopwood and Jack Grigg}, title={Transaction Identifier Non-Malleability}, howpublished={Zcash Improvement Proposal 244. Created January~6, 2021.}, url={https://zips.z.cash/zip-0244}, @@ -1438,7 +1437,7 @@ Last revised February~5, 2018.} @misc{ZIP-245, presort={ZIP-0245}, - author={Daira Emma Hopwood and Kris Nuttycombe}, + author={Kris Nuttycombe and {Daira\nbh{}Emma} Hopwood}, title={Transaction Identifier Digests & Signature Validation for {T}ransparent {Z}cash {E}xtensions}, howpublished={Zcash Improvement Proposal 245. Created January~13, 2021.}, url={https://zips.z.cash/zip-0245}, @@ -1447,7 +1446,7 @@ Last revised February~5, 2018.} @misc{ZIP-250, presort={ZIP-0250}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Deployment of the {H}eartwood Network Upgrade}, howpublished={Zcash Improvement Proposal 250. Created February~28, 2020.}, url={https://zips.z.cash/zip-0250}, @@ -1456,7 +1455,7 @@ Last revised February~5, 2018.} @misc{ZIP-251, presort={ZIP-0251}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Deployment of the {C}anopy Network Upgrade}, howpublished={Zcash Improvement Proposal 251. Created February~28, 2020.}, url={https://zips.z.cash/zip-0251}, @@ -1465,7 +1464,7 @@ Last revised February~5, 2018.} @misc{ZIP-252, presort={ZIP-0252}, - author={Teor and Daira Emma Hopwood}, + author={teor and {Daira\nbh{}Emma} Hopwood}, title={Deployment of the {NU5} Network Upgrade}, howpublished={Zcash Improvement Proposal 252. Created February~23, 2021.}, url={https://zips.z.cash/zip-0252}, @@ -1483,7 +1482,7 @@ Last revised February~5, 2018.} @misc{ZIP-316, presort={ZIP-0316}, - author={Daira Emma Hopwood and Nathan Wilcox and Taylor Hornby and Jack Grigg and Sean Bowe and Kris Nuttycombe and Ying Tong Lai}, + author={{Daira\nbh{}Emma} Hopwood and Nathan Wilcox and Taylor Hornby and Jack Grigg and Sean Bowe and Kris Nuttycombe and Greg Pfeil and {Ying~Tong} Lai}, title={Unified Addresses and Unified Viewing Keys}, howpublished={Zcash Improvement Proposal 316. Created April~7, 2021.}, url={https://zips.z.cash/zip-0316}, @@ -1501,14 +1500,14 @@ Last revised February~5, 2018.} @misc{BGG-mpc, presort={BGG-mpc}, author={Sean Bowe and Ariel Gabizon and Matthew Green}, - title={GitHub repository `\hairspace zcash/mpc'\hairspace: zk-SNARK parameter multi-party computation protocol}, + title={GitHub repository `\hairspace zcash/mpc'\hairspace: zk-{SNARK} parameter multi-party computation protocol}, url={https://github.com/zcash/mpc}, urldate={2017-01-06} } @misc{Hopwood2018, presort={Hopwood2018}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={GitHub repository `\hairspace daira/jubjub'\hairspace: {S}upporting evidence for security of the {J}ubjub curve to be used in {Z}cash}, url={https://github.com/daira/jubjub}, @@ -1518,7 +1517,7 @@ Last revised February~5, 2018.} @misc{Hopwood2020, presort={Hopwood2020}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={GitHub repository `\hairspace zcash/pasta'\hairspace: {G}enerator and supporting evidence for security of the {P}allas/{V}esta pair of elliptic curves suitable for {H}alo}, url={https://github.com/zcash/pasta}, @@ -1528,7 +1527,7 @@ Last revised February~5, 2018.} @misc{Hopwood2022, presort={Hopwood2022}, - author={Daira Emma Hopwood}, + author={{Daira\nbh{}Emma} Hopwood}, title={Explaining the Security of Zcash}, howpublished={Presentation at Zcon3. Slides and a link to the video are available at: \textit{GitHub repository `\hairspace daira/zcash-security'\hairspace: Code and documentation supporting security analysis of Zcash}.}, @@ -1737,7 +1736,7 @@ generic composition paradigm}, @misc{WCBTV2015, presort={WCBTV2015}, - author={Zooko Wilcox and Alessandro Chiesa and Eli Ben-Sasson and Eran Tromer and Madars Virza}, + author={Zooko Wilcox and Alessandro Chiesa and Eli {Ben\nbh{}Sasson} and Eran Tromer and Madars Virza}, title={A {B}ug in libsnark}, howpublished={Least Authority blog}, date={2015-05-16}, @@ -1842,7 +1841,7 @@ IEEE Computer Society Press, 1997; ISBN 0-8186-8197-7.} @misc{KvE2013, presort={KvE2013}, - author={Kaa1el and Hagen von Eitzen}, + author={Kaa1el and Hagen {von~Eitzen}}, title={If a group $G$ has odd order, then the square function is injective (answer).}, howpublished={Mathematics Stack Exchange}, url={https://math.stackexchange.com/a/522277/185422}, @@ -1873,7 +1872,7 @@ Proceedings of the 14th Annual International Cryptology Conference @misc{CvHP1991, presort={CvHP1991}, - author={David Chaum and Eugène {van Heijst} and Birgit Pfitzmann}, + author={David Chaum and Eugène {van~Heijst} and Birgit Pfitzmann}, title={Cryptographically {S}trong {U}ndeniable {S}ignatures, {U}nconditionally {S}ecure for the {S}igner}, date={1991-02}, publisher={Universität Karlsruhe Fakultät für Informatik}, @@ -1898,7 +1897,7 @@ Springer, 1992; ISBN 978-3-540-55188-1.} @inproceedings{CDvdG1987, presort={CDvdG1987}, - author={David Chaum and Ivan Damgård and Jeroen {van de Graaf}}, + author={David Chaum and Ivan Damgård and Jeroen {van~de~Graaf}}, title={Multiparty\, computations\, ensuring\, privacy\, of\, each\, party's\, input\, and\, correctness\, of\, the\, result}, date={1988-01}, booktitle={Advances\, in\, Cryptology - CRYPTO~'87. @@ -1937,7 +1936,8 @@ Proceedings of the 14th Annual International Cryptology Conference @inproceedings{ST1999, presort={ST1999}, - author={Tomas Sander and Amnon Ta--Shma}, + author={Tomas Sander and Amnon {Ta\nbh{}Shma}}, +% paper uses em-dash but e.g. https://simons.berkeley.edu/people/amnon-ta-shma uses Ta-Shma title={Auditable, {A}nonymous {E}lectronic {C}ash}, year={1999}, booktitle={Advances in Cryptology - CRYPTO~'99. @@ -1982,7 +1982,7 @@ Proceedings of the 19th Annual International Cryptology Conference @misc{Zcash-Orchard, presort={Zcash-Orchard}, - author={Daira Emma Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and Ying Tong Lai and Steven Smith}, + author={{Daira\nbh{}Emma} Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and {Ying~Tong} Lai and Steven Smith}, title={The {O}rchard Book}, url={https://zcash.github.io/orchard/}, urldate={2021-03-02} @@ -1990,7 +1990,7 @@ Proceedings of the 19th Annual International Cryptology Conference @misc{Zcash-halo2, presort={Zcash-halo2}, - author={Daira Emma Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and Ying Tong Lai and Steven Smith}, + author={{Daira\nbh{}Emma} Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and {Ying~Tong} Lai and Steven Smith}, title={The halo2 Book}, url={https://zcash.github.io/halo2/}, urldate={2021-03-23} @@ -1998,7 +1998,7 @@ Proceedings of the 19th Annual International Cryptology Conference @misc{zcashd-6459, presort={Zcashd-6459}, - author={Jack Grigg and Daira Emma Hopwood}, + author={Jack Grigg and {Daira\nbh{}Emma} Hopwood}, title={zcashd PR 6459: Migrate to zcash\_primitives 0.10}, comment={Merged on 2023-03-17.}, url={https://github.com/zcash/zcash/pull/6459}, diff --git a/zip-0000.rst b/zip-0000.rst index 920a840e..8cac9e24 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -18,7 +18,6 @@ License: BSD-2-Clause - Terminology =========== diff --git a/zip-0032.html b/zip-0032.html index c7328461..a9db866f 100644 --- a/zip-0032.html +++ b/zip-0032.html @@ -10,7 +10,7 @@ 
ZIP: 32
 Title: Shielded Hierarchical Deterministic Wallets
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Sean Bowe
          Kris Nuttycombe
          Ying Tong Lai
diff --git a/zip-0032.rst b/zip-0032.rst
index a66f930c..304f4727 100644
--- a/zip-0032.rst
+++ b/zip-0032.rst
@@ -3,7 +3,7 @@
   ZIP: 32
   Title: Shielded Hierarchical Deterministic Wallets
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Credits: Sean Bowe
            Kris Nuttycombe
            Ying Tong Lai
diff --git a/zip-0076.html b/zip-0076.html
index f983a889..62764335 100644
--- a/zip-0076.html
+++ b/zip-0076.html
@@ -9,7 +9,7 @@
         
ZIP: 76
 Title: Transaction Signature Validation before Overwinter
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Consensus
 Discussions-To: <https://github.com/zcash/zips/issues/130>

diff --git a/zip-0076.rst b/zip-0076.rst
index afd60067..35ba78a9 100644
--- a/zip-0076.rst
+++ b/zip-0076.rst
@@ -3,7 +3,7 @@
   ZIP: 76
   Title: Transaction Signature Validation before Overwinter
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Consensus
   Discussions-To: 
diff --git a/zip-0143.html b/zip-0143.html
index f162e950..5adb479d 100644
--- a/zip-0143.html
+++ b/zip-0143.html
@@ -9,7 +9,7 @@
         
ZIP: 143
 Title: Transaction Signature Validation for Overwinter
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Johnson Lau
          Pieter Wuille
          Bitcoin-ABC
diff --git a/zip-0143.rst b/zip-0143.rst
index f9b44f14..af07101d 100644
--- a/zip-0143.rst
+++ b/zip-0143.rst
@@ -3,7 +3,7 @@
   ZIP: 143
   Title: Transaction Signature Validation for Overwinter
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Credits: Johnson Lau
            Pieter Wuille
            Bitcoin-ABC
diff --git a/zip-0155.html b/zip-0155.html
index bde36482..a28ada2c 100644
--- a/zip-0155.html
+++ b/zip-0155.html
@@ -8,7 +8,7 @@
     

         
ZIP: 155
 Title: addrv2 message
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Wladimir J. van der Laan
          Zancas Wilcox
 Status: Proposed
diff --git a/zip-0155.rst b/zip-0155.rst
index 7850c3fa..21409162 100644
--- a/zip-0155.rst
+++ b/zip-0155.rst
@@ -2,7 +2,7 @@
 
   ZIP: 155
   Title: addrv2 message
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Wladimir J. van der Laan
            Zancas Wilcox
   Status: Proposed
diff --git a/zip-0173.html b/zip-0173.html
index d9fa2969..78829305 100644
--- a/zip-0173.html
+++ b/zip-0173.html
@@ -8,7 +8,7 @@
     

         
ZIP: 173
 Title: Bech32 Format
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Pieter Wuille <pieter.wuille@gmail.com>
          Greg Maxwell <greg@xiph.org>
          Rusty Russell
diff --git a/zip-0173.rst b/zip-0173.rst
index 4df7105b..8aebecce 100644
--- a/zip-0173.rst
+++ b/zip-0173.rst
@@ -2,7 +2,7 @@
 
   ZIP: 173
   Title: Bech32 Format
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Pieter Wuille 
            Greg Maxwell 
            Rusty Russell
diff --git a/zip-0201.html b/zip-0201.html
index 70d0e687..d7a384f7 100644
--- a/zip-0201.html
+++ b/zip-0201.html
@@ -8,7 +8,7 @@
     

         
ZIP: 201
 Title: Network Peer Management for Overwinter
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: Simon Liu
 Status: Final
 Category: Network
diff --git a/zip-0201.rst b/zip-0201.rst
index 9d2de1e9..2aae7850 100644
--- a/zip-0201.rst
+++ b/zip-0201.rst
@@ -2,7 +2,7 @@
 
   ZIP: 201
   Title: Network Peer Management for Overwinter
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Original-Authors: Simon Liu
   Status: Final
   Category: Network
diff --git a/zip-0202.html b/zip-0202.html
index a6d148ba..43a4a2cf 100644
--- a/zip-0202.html
+++ b/zip-0202.html
@@ -8,7 +8,7 @@
     

         
ZIP: 202
 Title: Version 3 Transaction Format for Overwinter
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: Simon Liu
 Status: Final
 Category: Consensus
diff --git a/zip-0202.rst b/zip-0202.rst
index b14d9394..adc7728d 100644
--- a/zip-0202.rst
+++ b/zip-0202.rst
@@ -2,7 +2,7 @@
 
   ZIP: 202
   Title: Version 3 Transaction Format for Overwinter
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Original-Authors: Simon Liu
   Status: Final
   Category: Consensus
diff --git a/zip-0203.html b/zip-0203.html
index 38d826a0..074d62c7 100644
--- a/zip-0203.html
+++ b/zip-0203.html
@@ -9,7 +9,7 @@
     

         
ZIP: 203
 Title: Transaction Expiry
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: Jay Graber
 Status: Final
 Category: Consensus
diff --git a/zip-0203.rst b/zip-0203.rst
index b1e1fa3b..3d2dbd03 100644
--- a/zip-0203.rst
+++ b/zip-0203.rst
@@ -2,7 +2,7 @@
 
   ZIP: 203
   Title: Transaction Expiry
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Original-Authors: Jay Graber
   Status: Final
   Category: Consensus
diff --git a/zip-0204.html b/zip-0204.html
index 54a743a6..150f8bfe 100644
--- a/zip-0204.html
+++ b/zip-0204.html
@@ -8,7 +8,7 @@
     

         
ZIP: 204
 Title: Zcash P2P Network Protocol
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Network
 Discussions-To: <https://github.com/zcash/zips/issues/352>

diff --git a/zip-0204.rst b/zip-0204.rst
index a018f512..77b5cdf5 100644
--- a/zip-0204.rst
+++ b/zip-0204.rst
@@ -2,7 +2,7 @@
 
   ZIP: 204
   Title: Zcash P2P Network Protocol
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Network
   Discussions-To: 
diff --git a/zip-0205.html b/zip-0205.html
index 92b534ca..73bc1a99 100644
--- a/zip-0205.html
+++ b/zip-0205.html
@@ -8,7 +8,7 @@
     

         
ZIP: 205
 Title: Deployment of the Sapling Network Upgrade
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Simon Liu
 Status: Final
 Category: Consensus / Network
diff --git a/zip-0205.rst b/zip-0205.rst
index 7d7e2833..963959a8 100644
--- a/zip-0205.rst
+++ b/zip-0205.rst
@@ -2,7 +2,7 @@
 
   ZIP: 205
   Title: Deployment of the Sapling Network Upgrade
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Simon Liu
   Status: Final
   Category: Consensus / Network
diff --git a/zip-0206.html b/zip-0206.html
index de5170f5..bf74ecad 100644
--- a/zip-0206.html
+++ b/zip-0206.html
@@ -8,7 +8,7 @@
     

         
ZIP: 206
 Title: Deployment of the Blossom Network Upgrade
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Simon Liu
 Status: Final
 Category: Consensus / Network
diff --git a/zip-0206.rst b/zip-0206.rst
index aacf3952..16d61138 100644
--- a/zip-0206.rst
+++ b/zip-0206.rst
@@ -2,7 +2,7 @@
 
   ZIP: 206
   Title: Deployment of the Blossom Network Upgrade
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Simon Liu
   Status: Final
   Category: Consensus / Network
diff --git a/zip-0207.html b/zip-0207.html
index 1fa6890e..10de0463 100644
--- a/zip-0207.html
+++ b/zip-0207.html
@@ -10,7 +10,7 @@
         
ZIP: 207
 Title: Funding Streams
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus
 Created: 2019-01-04
diff --git a/zip-0207.rst b/zip-0207.rst
index 0667aad1..8d8ed6b0 100644
--- a/zip-0207.rst
+++ b/zip-0207.rst
@@ -3,7 +3,7 @@
   ZIP: 207
   Title: Funding Streams
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Final
   Category: Consensus
   Created: 2019-01-04
diff --git a/zip-0208.html b/zip-0208.html
index d406ec64..4d4a014b 100644
--- a/zip-0208.html
+++ b/zip-0208.html
@@ -8,8 +8,8 @@
     

         
ZIP: 208
 Title: Shorter Block Target Spacing
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
-Original-Authors: Daira Emma Hopwood
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Original-Authors: Daira-Emma Hopwood
                   Simon Liu
 Status: Final
 Category: Consensus
diff --git a/zip-0208.rst b/zip-0208.rst
index d85ffe77..cf9840f2 100644
--- a/zip-0208.rst
+++ b/zip-0208.rst
@@ -2,8 +2,8 @@
 
   ZIP: 208
   Title: Shorter Block Target Spacing
-  Owners: Daira Emma Hopwood 
-  Original-Authors: Daira Emma Hopwood
+  Owners: Daira-Emma Hopwood 
+  Original-Authors: Daira-Emma Hopwood
                     Simon Liu
   Status: Final
   Category: Consensus
diff --git a/zip-0209.html b/zip-0209.html
index ba8a2191..83e0a7ee 100644
--- a/zip-0209.html
+++ b/zip-0209.html
@@ -9,7 +9,7 @@
         
ZIP: 209
 Title: Prohibit Negative Shielded Chain Value Pool Balances
 Owners: Sean Bowe <sean@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus
 Created: 2019-02-25
diff --git a/zip-0209.rst b/zip-0209.rst
index 5f11cb9c..ffb35f6f 100644
--- a/zip-0209.rst
+++ b/zip-0209.rst
@@ -3,7 +3,7 @@
   ZIP: 209
   Title: Prohibit Negative Shielded Chain Value Pool Balances
   Owners: Sean Bowe 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Final
   Category: Consensus
   Created: 2019-02-25
diff --git a/zip-0211.html b/zip-0211.html
index dbf97a69..ea75db48 100644
--- a/zip-0211.html
+++ b/zip-0211.html
@@ -8,7 +8,7 @@
     

         
ZIP: 211
 Title: Disabling Addition of New Value to the Sprout Chain Value Pool
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Sean Bowe
 Status: Final
 Category: Consensus
diff --git a/zip-0211.rst b/zip-0211.rst
index 3c9c07db..f857af18 100644
--- a/zip-0211.rst
+++ b/zip-0211.rst
@@ -2,7 +2,7 @@
 
   ZIP: 211
   Title: Disabling Addition of New Value to the Sprout Chain Value Pool
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Credits: Sean Bowe
   Status: Final
   Category: Consensus
diff --git a/zip-0214.html b/zip-0214.html
index 4c52384a..1e49cae6 100644
--- a/zip-0214.html
+++ b/zip-0214.html
@@ -8,7 +8,7 @@
     

         
ZIP: 214
 Title: Consensus rules for a Zcash Development Fund
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus
 Created: 2020-02-28
diff --git a/zip-0214.rst b/zip-0214.rst
index 5d8871d3..7efbda2d 100644
--- a/zip-0214.rst
+++ b/zip-0214.rst
@@ -2,7 +2,7 @@
 
   ZIP: 214
   Title: Consensus rules for a Zcash Development Fund
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Final
   Category: Consensus
   Created: 2020-02-28
diff --git a/zip-0216.html b/zip-0216.html
index 482288d3..e32adc95 100644
--- a/zip-0216.html
+++ b/zip-0216.html
@@ -10,7 +10,7 @@
         
ZIP: 216
 Title: Require Canonical Jubjub Point Encodings
 Owners: Jack Grigg <jack@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus
 Created: 2021-02-11
diff --git a/zip-0216.rst b/zip-0216.rst
index 6fc35343..c2aa8654 100644
--- a/zip-0216.rst
+++ b/zip-0216.rst
@@ -3,7 +3,7 @@
   ZIP: 216
   Title: Require Canonical Jubjub Point Encodings
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Final
   Category: Consensus
   Created: 2021-02-11
diff --git a/zip-0217.html b/zip-0217.html
index 854b6108..822e1fb6 100644
--- a/zip-0217.html
+++ b/zip-0217.html
@@ -8,7 +8,7 @@
     

         
ZIP: 217
 Title: Aggregate Signatures
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Consensus
 Discussions-To: <https://github.com/zcash/zcash/issues/2914>

diff --git a/zip-0217.rst b/zip-0217.rst
index 672e4be1..4562d86f 100644
--- a/zip-0217.rst
+++ b/zip-0217.rst
@@ -2,7 +2,7 @@
 
   ZIP: 217
   Title: Aggregate Signatures
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Consensus
   Discussions-To: 
diff --git a/zip-0219.html b/zip-0219.html
index 135cb6ba..296aa847 100644
--- a/zip-0219.html
+++ b/zip-0219.html
@@ -8,7 +8,7 @@
     

         
ZIP: 219
 Title: Disabling Addition of New Value to the Sapling Chain Value Pool
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Consensus
 Discussions-To: <https://github.com/zcash/zips/issues/428>

diff --git a/zip-0219.rst b/zip-0219.rst
index 31d135c3..313032e9 100644
--- a/zip-0219.rst
+++ b/zip-0219.rst
@@ -2,7 +2,7 @@
 
   ZIP: 219
   Title: Disabling Addition of New Value to the Sapling Chain Value Pool
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Consensus
   Discussions-To: 
diff --git a/zip-0220.html b/zip-0220.html
index 17eba3f3..a557d39a 100644
--- a/zip-0220.html
+++ b/zip-0220.html
@@ -9,7 +9,7 @@
         
ZIP: 220
 Title: Zcash Shielded Assets
 Owners: Jack Grigg <jack@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Withdrawn
 Category: Consensus
 Discussions-To: <https://github.com/zcash/zcash/issues/830>
diff --git a/zip-0220.rst b/zip-0220.rst
index 563375a8..5b9b8ee0 100644
--- a/zip-0220.rst
+++ b/zip-0220.rst
@@ -3,7 +3,7 @@
   ZIP: 220
   Title: Zcash Shielded Assets
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Withdrawn
   Category: Consensus
   Discussions-To: 
diff --git a/zip-0222.html b/zip-0222.html
index 33e2237b..8bac39fa 100644
--- a/zip-0222.html
+++ b/zip-0222.html
@@ -11,7 +11,7 @@ Title: Transparent Zcash Extensions
 Owners: Jack Grigg <jack@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
 Credits: Zaki Manian
-         Daira Emma Hopwood
+         Daira-Emma Hopwood
          Sean Bowe
 Status: Draft
 Category: Consensus
@@ -282,7 +282,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero in 
Acknowledgements 

-            
The handler semantics of tze_verify were suggested by Zaki Manian, drawing on the design of Cosmos. Daira Emma Hopwood and Sean Bowe gave useful feedback on an early draft of this ZIP, and helped to analyse the various sources of transaction ID malleability.

+            
The handler semantics of tze_verify were suggested by Zaki Manian, drawing on the design of Cosmos. Daira-Emma Hopwood and Sean Bowe gave useful feedback on an early draft of this ZIP, and helped to analyse the various sources of transaction ID malleability.

             
We would also like to thank the numerous other individuals who participated in discussions at Zcon1 that led to the earlier draft version of this ZIP.

         

         
References 

diff --git a/zip-0222.rst b/zip-0222.rst
index 156e65ee..440ec86e 100644
--- a/zip-0222.rst
+++ b/zip-0222.rst
@@ -5,7 +5,7 @@
   Owners: Jack Grigg 
           Kris Nuttycombe 
   Credits: Zaki Manian
-           Daira Emma Hopwood
+           Daira-Emma Hopwood
            Sean Bowe
   Status: Draft
   Category: Consensus
@@ -311,7 +311,7 @@ Acknowledgements
 ================
 
 The handler semantics of ``tze_verify`` were suggested by Zaki Manian, drawing on the
-design of Cosmos. Daira Emma Hopwood and Sean Bowe gave useful feedback on an early draft of
+design of Cosmos. Daira-Emma Hopwood and Sean Bowe gave useful feedback on an early draft of
 this ZIP, and helped to analyse the various sources of transaction ID malleability.
 
 We would also like to thank the numerous other individuals who participated in discussions
diff --git a/zip-0224.html b/zip-0224.html
index dfde043b..211d87e2 100644
--- a/zip-0224.html
+++ b/zip-0224.html
@@ -9,11 +9,11 @@
     

         
ZIP: 224
 Title: Orchard Shielded Protocol
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
-        Ying Tong Lai <yingtong@electriccoin.co>
+Original-Authors: Ying Tong Lai
 Status: Final
 Category: Consensus
 Created: 2021-02-27
diff --git a/zip-0224.rst b/zip-0224.rst
index 789750bc..b3b75fa3 100644
--- a/zip-0224.rst
+++ b/zip-0224.rst
@@ -2,11 +2,11 @@
 
   ZIP: 224
   Title: Orchard Shielded Protocol
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
-          Ying Tong Lai 
+  Original-Authors: Ying Tong Lai
   Status: Final
   Category: Consensus
   Created: 2021-02-27
diff --git a/zip-0225.html b/zip-0225.html
index 2830d955..1ab6b941 100644
--- a/zip-0225.html
+++ b/zip-0225.html
@@ -9,11 +9,11 @@
     

         
ZIP: 225
 Title: Version 5 Transaction Format
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
-        Ying Tong Lai <yingtong@electriccoin.co>
+Original-Authors: Ying Tong Lai
 Status: Final
 Category: Consensus
 Created: 2021-02-28
diff --git a/zip-0225.rst b/zip-0225.rst
index 08b7c2ea..a4bf7ce9 100644
--- a/zip-0225.rst
+++ b/zip-0225.rst
@@ -2,11 +2,11 @@
 
   ZIP: 225
   Title: Version 5 Transaction Format
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
-          Ying Tong Lai 
+  Original-Authors: Ying Tong Lai
   Status: Final
   Category: Consensus
   Created: 2021-02-28
diff --git a/zip-0226.html b/zip-0226.html
index 4ebbc36b..dfa6cf2b 100644
--- a/zip-0226.html
+++ b/zip-0226.html
@@ -11,7 +11,7 @@
 Title: Transfer and Burn of Zcash Shielded Assets
 Owners: Pablo Kogan <pablo@qed-it.com>
         Vivek Arte <vivek@qed-it.com>
-        Daira-Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <str4d@electriccoin.co>
 Credits: Daniel Benarroch
          Aurelien Nicolas
diff --git a/zip-0226.rst b/zip-0226.rst
index 4d0e1c2f..cb939efc 100644
--- a/zip-0226.rst
+++ b/zip-0226.rst
@@ -4,7 +4,7 @@
   Title: Transfer and Burn of Zcash Shielded Assets
   Owners: Pablo Kogan 
           Vivek Arte 
-          Daira-Emma Hopwood 
+          Daira-Emma Hopwood 
           Jack Grigg 
   Credits: Daniel Benarroch
            Aurelien Nicolas
diff --git a/zip-0227.html b/zip-0227.html
index 86a06c33..91722f63 100644
--- a/zip-0227.html
+++ b/zip-0227.html
@@ -11,7 +11,7 @@
 Title: Issuance of Zcash Shielded Assets
 Owners: Pablo Kogan <pablo@qed-it.com>
         Vivek Arte <vivek@qed-it.com>
-        Daira-Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <str4d@electriccoin.co>
 Credits: Daniel Benarroch
          Aurelien Nicolas
diff --git a/zip-0227.rst b/zip-0227.rst
index 89e837f4..f150c1c8 100644
--- a/zip-0227.rst
+++ b/zip-0227.rst
@@ -4,7 +4,7 @@
   Title: Issuance of Zcash Shielded Assets
   Owners: Pablo Kogan 
           Vivek Arte 
-          Daira-Emma Hopwood 
+          Daira-Emma Hopwood 
           Jack Grigg 
   Credits: Daniel Benarroch
            Aurelien Nicolas
diff --git a/zip-0228.html b/zip-0228.html
index 1917f4e6..e43bedfe 100644
--- a/zip-0228.html
+++ b/zip-0228.html
@@ -10,7 +10,7 @@
 Title: Asset Swaps for Zcash Shielded Assets
 Owners: Pablo Kogan <pablo@qed-it.com>
         Vivek Arte <vivek@qed-it.com>
-        Daira-Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <str4d@electriccoin.co>
 Credits: Daniel Benarroch
          Aurelien Nicolas
diff --git a/zip-0228.rst b/zip-0228.rst
index 024c4f77..c1c19c70 100644
--- a/zip-0228.rst
+++ b/zip-0228.rst
@@ -4,7 +4,7 @@
   Title: Asset Swaps for Zcash Shielded Assets
   Owners: Pablo Kogan 
           Vivek Arte 
-          Daira-Emma Hopwood 
+          Daira-Emma Hopwood 
           Jack Grigg 
   Credits: Daniel Benarroch
            Aurelien Nicolas
diff --git a/zip-0230.html b/zip-0230.html
index dc1547dc..2afcac67 100644
--- a/zip-0230.html
+++ b/zip-0230.html
@@ -9,7 +9,7 @@
     

         
ZIP: 230
 Title: Version 6 Transaction Format
-Owners: Daira-Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
diff --git a/zip-0230.rst b/zip-0230.rst
index e807d614..a4f4b8b4 100644
--- a/zip-0230.rst
+++ b/zip-0230.rst
@@ -2,7 +2,7 @@
 
   ZIP: 230
   Title: Version 6 Transaction Format
-  Owners: Daira-Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
diff --git a/zip-0231.html b/zip-0231.html
index cac8d4d1..877430c9 100644
--- a/zip-0231.html
+++ b/zip-0231.html
@@ -10,7 +10,7 @@
 Title: Decouple Memos from Transaction Outputs
 Owners: Jack Grigg <jack@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Sean Bowe
          Nate Wilcox
 Status: Reserved
diff --git a/zip-0231.rst b/zip-0231.rst
index 9c6275ec..1bbed369 100644
--- a/zip-0231.rst
+++ b/zip-0231.rst
@@ -4,7 +4,7 @@
   Title: Decouple Memos from Transaction Outputs
   Owners: Jack Grigg 
           Kris Nuttycombe 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Credits: Sean Bowe
            Nate Wilcox
   Status: Reserved
diff --git a/zip-0239.html b/zip-0239.html
index 4d09ee36..f4d1626e 100644
--- a/zip-0239.html
+++ b/zip-0239.html
@@ -8,7 +8,7 @@
     

         
ZIP: 239
 Title: Relay of Version 5 Transactions
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
 Status: Final
 Category: Network
diff --git a/zip-0239.rst b/zip-0239.rst
index 65ff5cd8..23f18ffa 100644
--- a/zip-0239.rst
+++ b/zip-0239.rst
@@ -2,7 +2,7 @@
 
   ZIP: 239
   Title: Relay of Version 5 Transactions
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
   Status: Final
   Category: Network
diff --git a/zip-0243.html b/zip-0243.html
index 2e497df5..e0fa280a 100644
--- a/zip-0243.html
+++ b/zip-0243.html
@@ -9,7 +9,7 @@
         
ZIP: 243
 Title: Transaction Signature Validation for Sapling
 Owners: Jack Grigg <str4d@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Simon Liu
 Status: Final
 Category: Consensus
diff --git a/zip-0243.rst b/zip-0243.rst
index e1190850..47c574b0 100644
--- a/zip-0243.rst
+++ b/zip-0243.rst
@@ -3,7 +3,7 @@
   ZIP: 243
   Title: Transaction Signature Validation for Sapling
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Credits: Simon Liu
   Status: Final
   Category: Consensus
diff --git a/zip-0244.html b/zip-0244.html
index 8cc9b216..8f73e451 100644
--- a/zip-0244.html
+++ b/zip-0244.html
@@ -10,7 +10,7 @@
         
ZIP: 244
 Title: Transaction Identifier Non-Malleability
 Owners: Kris Nuttycombe <kris@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <str4d@electriccoin.co>
 Status: Final
 Category: Consensus
diff --git a/zip-0244.rst b/zip-0244.rst
index 496ae133..7dce6b2e 100644
--- a/zip-0244.rst
+++ b/zip-0244.rst
@@ -3,7 +3,7 @@
   ZIP: 244
   Title: Transaction Identifier Non-Malleability
   Owners: Kris Nuttycombe 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
           Jack Grigg 
   Status: Final
   Category: Consensus
diff --git a/zip-0245.html b/zip-0245.html
index 63ad4c9b..0a44da2f 100644
--- a/zip-0245.html
+++ b/zip-0245.html
@@ -9,6 +9,7 @@
         
ZIP: 245
 Title: Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions
 Owners: Kris Nuttycombe <kris@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Draft
 Category: Consensus
 Created: 2021-01-13
diff --git a/zip-0245.rst b/zip-0245.rst
index e8350a52..fd55a7c9 100644
--- a/zip-0245.rst
+++ b/zip-0245.rst
@@ -3,6 +3,7 @@
   ZIP: 245
   Title: Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions
   Owners: Kris Nuttycombe 
+          Daira-Emma Hopwood 
   Status: Draft
   Category: Consensus
   Created: 2021-01-13
diff --git a/zip-0250.html b/zip-0250.html
index aac84c5c..0c942d7e 100644
--- a/zip-0250.html
+++ b/zip-0250.html
@@ -8,7 +8,7 @@
     

         
ZIP: 250
 Title: Deployment of the Heartwood Network Upgrade
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus / Network
 Created: 2020-02-28
diff --git a/zip-0250.rst b/zip-0250.rst
index 755c56c5..0c0757a8 100644
--- a/zip-0250.rst
+++ b/zip-0250.rst
@@ -2,7 +2,7 @@
 
   ZIP: 250
   Title: Deployment of the Heartwood Network Upgrade
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Final
   Category: Consensus / Network
   Created: 2020-02-28
diff --git a/zip-0251.html b/zip-0251.html
index 8cbbc612..be3a7505 100644
--- a/zip-0251.html
+++ b/zip-0251.html
@@ -8,7 +8,7 @@
     

         
ZIP: 251
 Title: Deployment of the Canopy Network Upgrade
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus / Network
 Created: 2020-02-28
diff --git a/zip-0251.rst b/zip-0251.rst
index f9e30de8..c906e0b6 100644
--- a/zip-0251.rst
+++ b/zip-0251.rst
@@ -2,7 +2,7 @@
 
   ZIP: 251
   Title: Deployment of the Canopy Network Upgrade
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Final
   Category: Consensus / Network
   Created: 2020-02-28
diff --git a/zip-0252.html b/zip-0252.html
index 326ce077..92f931d3 100644
--- a/zip-0252.html
+++ b/zip-0252.html
@@ -9,7 +9,7 @@
         
ZIP: 252
 Title: Deployment of the NU5 Network Upgrade
 Owners: teor <teor@zfnd.org>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Final
 Category: Consensus / Network
 Created: 2021-02-23
diff --git a/zip-0252.rst b/zip-0252.rst
index a7a291bc..93804a61 100644
--- a/zip-0252.rst
+++ b/zip-0252.rst
@@ -3,7 +3,7 @@
   ZIP: 252
   Title: Deployment of the NU5 Network Upgrade
   Owners: teor 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Final
   Category: Consensus / Network
   Created: 2021-02-23
diff --git a/zip-0253.html b/zip-0253.html
new file mode 100644
index 00000000..089d649f
--- /dev/null
+++ b/zip-0253.html
@@ -0,0 +1,17 @@
+
+
+
+    ZIP 253: Deployment of the NU6 Network Upgrade
+    
+
+
+    

+        
ZIP: 253
+Title: Deployment of the NU6 Network Upgrade
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Status: Reserved
+Category: Consensus / Network
+Discussions-To: <https://github.com/zcash/zips/issues/806>

+    

+
+
\ No newline at end of file
diff --git a/zip-0300.html b/zip-0300.html
index 3e95321e..b8ec2888 100644
--- a/zip-0300.html
+++ b/zip-0300.html
@@ -8,7 +8,7 @@
     

         
ZIP: 300
 Title: Cross-chain Atomic Transactions
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: Jay Graber
 Status: Proposed
 Category: Informational
diff --git a/zip-0300.rst b/zip-0300.rst
index a3cacdfe..17eb9b03 100644
--- a/zip-0300.rst
+++ b/zip-0300.rst
@@ -2,7 +2,7 @@
 
   ZIP: 300
   Title: Cross-chain Atomic Transactions
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Original-Authors: Jay Graber
   Status: Proposed
   Category: Informational
diff --git a/zip-0301.html b/zip-0301.html
index d575f647..e8411913 100644
--- a/zip-0301.html
+++ b/zip-0301.html
@@ -10,7 +10,7 @@
 Title: Zcash Stratum Protocol
 Owners: Jack Grigg <str4d@electriccoin.co>
 Credits: 5a1t
-         Daira Emma Hopwood
+         Daira-Emma Hopwood
          Marek Palatinus (slush) and colleagues
          Jelle Bourdeaud'hui (razakal)
          ocminer
@@ -336,7 +336,7 @@ License: MIT

             
Thanks to:

             
    
                 
  • 5a1t for the initial brainstorming session.
    • 
-                
  • Daira Emma Hopwood for their input on API selection and design.
    • 
+                
  • Daira-Emma Hopwood for hir input on API selection and design.
    • 
                 
  • Marek Palatinus (slush) and his colleagues for their refinements, suggestions, and robust discussion.
    • 
                 
  • Jelle Bourdeaud'hui (razakal) and ocminer for their help with testing and finding implementation bugs in the specification.
    • 
             

diff --git a/zip-0301.rst b/zip-0301.rst
index 5c05bc03..c76161db 100644
--- a/zip-0301.rst
+++ b/zip-0301.rst
@@ -4,7 +4,7 @@
   Title: Zcash Stratum Protocol
   Owners: Jack Grigg 
   Credits: 5a1t
-           Daira Emma Hopwood
+           Daira-Emma Hopwood
            Marek Palatinus (slush) and colleagues
            Jelle Bourdeaud'hui (razakal)
            ocminer
@@ -477,7 +477,7 @@ Thanks to:
 
 - 5a1t for the initial brainstorming session.
 
-- Daira Emma Hopwood for their input on API selection and design.
+- Daira-Emma Hopwood for hir input on API selection and design.
 
 - Marek Palatinus (slush) and his colleagues for their refinements, suggestions, and
   robust discussion.
diff --git a/zip-0304.html b/zip-0304.html
index df9d5d80..453038ad 100644
--- a/zip-0304.html
+++ b/zip-0304.html
@@ -10,7 +10,7 @@
         
ZIP: 304
 Title: Sapling Address Signatures
 Owners: Jack Grigg <jack@electriccoin.co>
-Credits: Daira Emma Hopwood <daira@electriccoin.co>
+Credits: Daira-Emma Hopwood <daira-emma@electriccoin.co>
          Sean Bowe <sean@electriccoin.co>
 Status: Draft
 Category: Standards / RPC / Wallet
diff --git a/zip-0304.rst b/zip-0304.rst
index a0e48b94..995eefc7 100644
--- a/zip-0304.rst
+++ b/zip-0304.rst
@@ -3,7 +3,7 @@
   ZIP: 304
   Title: Sapling Address Signatures
   Owners: Jack Grigg 
-  Credits: Daira Emma Hopwood 
+  Credits: Daira-Emma Hopwood 
            Sean Bowe 
   Status: Draft
   Category: Standards / RPC / Wallet
diff --git a/zip-0305.html b/zip-0305.html
index fc1e5e11..e430de06 100644
--- a/zip-0305.html
+++ b/zip-0305.html
@@ -8,7 +8,7 @@
     

         
ZIP: 305
 Title: Best Practices for Hardware Wallets supporting Sapling
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/346>

diff --git a/zip-0305.rst b/zip-0305.rst
index 1f3d2fbe..a7695fd0 100644
--- a/zip-0305.rst
+++ b/zip-0305.rst
@@ -2,7 +2,7 @@
 
   ZIP: 305
   Title: Best Practices for Hardware Wallets supporting Sapling
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Wallet
   Discussions-To: 
diff --git a/zip-0306.html b/zip-0306.html
index f535f3ae..6847e02c 100644
--- a/zip-0306.html
+++ b/zip-0306.html
@@ -8,7 +8,7 @@
     

         
ZIP: 306
 Title: Security Considerations for Anchor Selection
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Informational
 Discussions-To: <https://github.com/zcash/zips/issues/351>

diff --git a/zip-0306.rst b/zip-0306.rst
index 00da5463..76b95ead 100644
--- a/zip-0306.rst
+++ b/zip-0306.rst
@@ -2,7 +2,7 @@
 
   ZIP: 306
   Title: Security Considerations for Anchor Selection
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Informational
   Discussions-To: 
diff --git a/zip-0307.html b/zip-0307.html
index ed49efa1..5b36f0d0 100644
--- a/zip-0307.html
+++ b/zip-0307.html
@@ -10,7 +10,7 @@
         
ZIP: 307
 Title: Light Client Protocol for Payment Detection
 Owners: Jack Grigg <jack@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Original-Authors: George Tankersley
 Credits: Matthew Green
 Category: Standards / Ecosystem
diff --git a/zip-0307.rst b/zip-0307.rst
index cfc65bf1..2c3e8598 100644
--- a/zip-0307.rst
+++ b/zip-0307.rst
@@ -3,7 +3,7 @@
   ZIP: 307
   Title: Light Client Protocol for Payment Detection
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Original-Authors: George Tankersley
   Credits: Matthew Green
   Category: Standards / Ecosystem
diff --git a/zip-0308.html b/zip-0308.html
index 169ea644..6afcc473 100644
--- a/zip-0308.html
+++ b/zip-0308.html
@@ -8,8 +8,8 @@
     

         
ZIP: 308
 Title: Sprout to Sapling Migration
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
-Original-Authors: Daira Emma Hopwood
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Original-Authors: Daira-Emma Hopwood
                   Eirik Ogilvie-Wigley
 Status: Final
 Category: Standards / RPC / Wallet
diff --git a/zip-0308.rst b/zip-0308.rst
index 5ea28402..ed039af2 100644
--- a/zip-0308.rst
+++ b/zip-0308.rst
@@ -2,8 +2,8 @@
 
   ZIP: 308
   Title: Sprout to Sapling Migration
-  Owners: Daira Emma Hopwood 
-  Original-Authors: Daira Emma Hopwood
+  Owners: Daira-Emma Hopwood 
+  Original-Authors: Daira-Emma Hopwood
                     Eirik Ogilvie-Wigley
   Status: Final
   Category: Standards / RPC / Wallet
diff --git a/zip-0310.html b/zip-0310.html
index 17962bfa..0c9c2b30 100644
--- a/zip-0310.html
+++ b/zip-0310.html
@@ -8,7 +8,7 @@
     

         
ZIP: 310
 Title: Security Properties of Sapling Viewing Keys
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
 Status: Draft
 Category: Informational
diff --git a/zip-0310.rst b/zip-0310.rst
index e3b665d4..843f6e3c 100644
--- a/zip-0310.rst
+++ b/zip-0310.rst
@@ -2,7 +2,7 @@
 
   ZIP: 310
   Title: Security Properties of Sapling Viewing Keys
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
   Status: Draft
   Category: Informational
diff --git a/zip-0313.html b/zip-0313.html
index f992628c..d5aead65 100644
--- a/zip-0313.html
+++ b/zip-0313.html
@@ -9,7 +9,7 @@
         
ZIP: 313
 Title: Reduce Conventional Transaction Fee to 1000 zatoshis
 Owners: Aditya Bharadwaj <nighthawkwallet@protonmail.com>
-Credits: Daira Emma Hopwood
+Credits: Daira-Emma Hopwood
          Deirdre Connolly
          Nathan Wilcox
 Status: Obsolete
@@ -81,7 +81,7 @@ Pull-Request: <https://githu
             
In zcashd this fee change is implemented in version 4.2.0 (not dependent on block height), and in that version is limited to transactions created using z_* RPC APIs. It is planned to extend this to all transactions in a future version 7.

         

         
Acknowledgements 

-            
Thanks to Nathan Wilcox for suggesting improvements to the denial of service section. Thanks to Daira Emma Hopwood and Deirdre Connolly for reviewing and fixing the wording in this ZIP.

+            
Thanks to Nathan Wilcox for suggesting improvements to the denial of service section. Thanks to Daira-Emma Hopwood and Deirdre Connolly for reviewing and fixing the wording in this ZIP.

         

         
References 

             
diff --git a/zip-0313.rst b/zip-0313.rst
index 185b7845..86cc554a 100644
--- a/zip-0313.rst
+++ b/zip-0313.rst
@@ -3,7 +3,7 @@
   ZIP: 313
   Title: Reduce Conventional Transaction Fee to 1000 zatoshis
   Owners: Aditya Bharadwaj 
-  Credits: Daira Emma Hopwood
+  Credits: Daira-Emma Hopwood
            Deirdre Connolly
            Nathan Wilcox
   Status: Obsolete
@@ -199,7 +199,7 @@ Acknowledgements
 ================
 
 Thanks to Nathan Wilcox for suggesting improvements to the denial of service
-section. Thanks to Daira Emma Hopwood and Deirdre Connolly for reviewing and fixing
+section. Thanks to Daira-Emma Hopwood and Deirdre Connolly for reviewing and fixing
 the wording in this ZIP.
 
 
diff --git a/zip-0315.html b/zip-0315.html
index 77fa4867..810c1900 100644
--- a/zip-0315.html
+++ b/zip-0315.html
@@ -8,7 +8,7 @@
     

         
ZIP: 315
 Title: Best Practices for Wallet Handling of Multiple Pools
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
 Status: Reserved
 Category: Wallet
diff --git a/zip-0315.rst b/zip-0315.rst
index 141cac40..883b18cc 100644
--- a/zip-0315.rst
+++ b/zip-0315.rst
@@ -2,7 +2,7 @@
 
   ZIP: 315
   Title: Best Practices for Wallet Handling of Multiple Pools
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
   Status: Reserved
   Category: Wallet
diff --git a/zip-0316.html b/zip-0316.html
index 31323f82..7aa64379 100644
--- a/zip-0316.html
+++ b/zip-0316.html
@@ -9,14 +9,14 @@
     

         
ZIP: 316
 Title: Unified Addresses and Unified Viewing Keys
-Owners: Daira-Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Nathan Wilcox <nathan@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
-        Greg Pfeil <greg@electriccoin.co>
+Original-Authors: Greg Pfeil
+                  Ying Tong Lai
 Credits: Taylor Hornby
-         Ying Tong Lai
          Stephen Smith
 Status: Revision 0: Final, Revision 1: Proposed
 Category: Standards / RPC / Wallet
@@ -34,7 +34,7 @@ Discussions-To: <https://g
                 
Consumer

                 
A wallet or other software that can make use of an Address or Viewing Key that it is given.

                 
Sender

-                
A wallet or other software that can send transfers of assets, or other consensus state side-effects defined in future. Senders are a subset of Consumers.

+                
A wallet or other software that can send transfers of assets, or other side effects to consensus state that may be defined in future. Senders are a subset of Consumers.

                 
Receiver

                 
The necessary information to transfer an asset to a Recipient that generated that Receiver using a specific Transfer Protocol. Each Receiver is associated unambiguously with a specific Receiver Type, identified by an integer Typecode.

                 
Receiver Encoding

@@ -165,8 +165,16 @@ Discussions-To: <https://g
                     
  • Revision 1: This version adds support for MUST-understand Typecodes and Address Expiration Metadata. It also drops the restriction that a UA/UVK must contain at least one shielded Item.
    • 
                 
                 
    A Revision 0 UA/UVK is distinguished from a Revision 1 UA/UVK by its Human-Readable Part, as follows.
    
-                
    Let prefix be: * “u”, if this is a UA/UVK prior to Revision 1; * “ur”, if this is a UA/UVK from Revision 1 onward.
    
-                
    The Human-Readable Parts (as defined in 36) of Unified Addresses are defined as: * prefix, for Unified Addresses on Mainnet; * prefix || “test”, for Unified Addresses on Testnet.
    
+                
    Let prefix be:
    
+                
      
+                    
    • “u”, if this is a UA/UVK prior to Revision 1;
      • 
+                    
    • “ur”, if this is a UA/UVK from Revision 1 onward.
      • 
+                
    
+                
    The Human-Readable Parts (as defined in 36) of Unified Addresses are defined as:
    
+                
      
+                    
    • prefix, for Unified Addresses on Mainnet;
      • 
+                    
    • prefix || “test”, for Unified Addresses on Testnet.
      • 
+                
    
                 
    The Human-Readable Parts of Unified Viewing Keys are defined as:
    
                 
+                
    While support for Revision 1 UAs/UVKs is still being rolled out across the Zcash ecosystem, a Producer can maximize interoperability by generating a Revision 0 UA/UVK in cases where the conditions on its use are met (i.e. there are no MUST-understand Metadata Items, and at least one shielded item). At some point when Revision 1 UA/UVKs are widely supported, this will be unnecessary and it will be sufficient to always produce Revision 1 UA/UVKs.
    
             
    
             
    Encoding of Unified Addresses 
    
                 
    Rather than defining a Bech32 string encoding of Orchard Shielded Payment Addresses, we instead define a Unified Address format that is able to encode a set of Receivers of different types. This enables the Consumer of a Unified Address to choose the Receiver of the best type it supports, providing a better user experience as new Receiver Types are added in the future.
    
@@ -197,7 +206,7 @@ Discussions-To: <https://g
                 
    For example, consider a wallet that supports sending funds to Orchard Receivers, and does not support sending to any Receiver Type that is preferred over Orchard. If that wallet is given a UA that includes an Orchard Receiver and possibly other Receivers, it MUST send to the Orchard Receiver.
    
                 
    The raw encoding of a Unified Address is a concatenation of
                     \((\mathtt{typecode}, \mathtt{length}, \mathtt{addr})\)
-                 encodings of the consituent Receivers, in ascending order of Typecode:
    
+                 encodings of the constituent Receivers, in ascending order of Typecode:
    
                 
    
             
    Address Expiration Metadata 
    
@@ -666,17 +675,37 @@ c^{n+m}}{q}.\)
                     
    In order to prevent the generic attack against nonmalleability, there needs to be some redundancy in the encoding. Therefore, the Producer of a Unified Address, UFVK, or UIVK appends the HRP, padded to 16 bytes with zero bytes, to the raw encoding, then applies
                         \(\mathsf{F4Jumble}\)
                      before encoding the result with Bech32m.
    
-                    
    The Consumer rejects any Bech32m-decoded byte sequence that is less than 48 bytes or greater than
+                    
    The Consumer rejects any Bech32m-decoded byte sequence that is less than 38 bytes or greater than
                         \(\ell^\mathsf{MAX}_M\)
                      bytes; otherwise it applies
                         \(\mathsf{F4Jumble}^{-1}.\)
                      It rejects any result that does not end in the expected 16-byte padding, before stripping these 16 bytes and parsing the result.
    
-                    
    (48 bytes allows for the minimum size of a shielded UA, UFVK, or UIVK Item encoding to be 32 bytes, taking into account 16 bytes of padding. Although there is currently no shielded Item encoding that short, it is plausible that one might be added in future.
+                
    
+                
    Rationale for length restrictions 
    
+                
    
+Click to show/hide
+                    
    A minimum input length to
+                        \(\mathsf{F4Jumble}^{-1}\)
+                     of 38 bytes allows for the minimum size of a UA/UVK Item encoding to be 22 bytes including the typecode and length, taking into account 16 bytes of padding. This allows for a UA containing only a Transparent P2PKH Receiver:
    
+                    
      
+                        
    • Transparent P2PKH Receiver Item:
+                            
        
+                                
      • 1-byte typecode
        • 
+                                
      • 1-byte encoding of length
        • 
+                                
      • 20-byte transparent address hash
        • 
+                            
      
+                        
      • 
+                    
    
+                    
    
                         \(\ell^\mathsf{MAX}_M\)
                      bytes is the largest input/output size supported by
                         \(\mathsf{F4Jumble}.\)
-                    )
    
-                
    
+                    
    
+                    
    Allowing only a Transparent P2PKH Receiver is consistent with dropping the requirement to have at least one shielded Item in Revision 1 UA/UVKs (see rationale).
    
+                    
    Note that Revision 0 of this ZIP specified a minimum input length to
+                        \(\mathsf{F4Jumble}^{-1}\)
+                     of 48 bytes. Since there were no sets of UA/UVK Item Encodings valid in Revision 0 to which a byte sequence (after removal of the 16-byte padding) of length between 22 and 31 bytes inclusive could be parsed, the difference between the 38 and 48-byte restrictions is not observable, other than potentially affecting which error is reported. A Consumer supporting Revision 1 of this specification MAY therefore apply either the 48-byte or 38-byte minimum to Revision 0 UA/UVKs.
    
+                
    
                 
    Heuristic analysis 
    
                     
    A 3-round unkeyed Feistel, as shown, is not sufficient:
    
                     
    
@@ -751,7 +780,7 @@ c^{n+m}}{q}.\)
                             \(y' \neq y,\)
                          all four pieces are randomized.
                     
-                    
    Note that the size of each piece is at least 24 bytes.
    
+                    
    Note that the size of each piece is at least 19 bytes.
    
                     
    It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.
    
                     
    The padding contains the HRP so that the HRP has the same protection against malleation as the rest of the address. This may help against cross-network attacks, or attacks that confuse addresses with viewing keys.
    
                 
    
diff --git a/zip-0316.rst b/zip-0316.rst
index 7e08365e..92fd97b0 100644
--- a/zip-0316.rst
+++ b/zip-0316.rst
@@ -2,14 +2,14 @@
 
   ZIP: 316
   Title: Unified Addresses and Unified Viewing Keys
-  Owners: Daira-Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Nathan Wilcox 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
-          Greg Pfeil 
+  Original-Authors: Greg Pfeil
+                    Ying Tong Lai
   Credits: Taylor Hornby
-           Ying Tong Lai
            Stephen Smith
   Status: Revision 0: Final, Revision 1: Proposed
   Category: Standards / RPC / Wallet
@@ -38,8 +38,8 @@ Consumer
   that it is given.
 Sender
   A wallet or other software that can send transfers of assets, or other
-  consensus state side-effects defined in future. Senders are a subset of
-  Consumers.
+  side effects to consensus state that may be defined in future. Senders are a
+  subset of Consumers.
 Receiver
   The necessary information to transfer an asset to a Recipient that generated
   that Receiver using a specific Transfer Protocol. Each Receiver is associated
@@ -393,7 +393,7 @@ Orchard Receiver.
 
 The raw encoding of a Unified Address is a concatenation of
 :math:`(\mathtt{typecode}, \mathtt{length}, \mathtt{addr})` encodings
-of the consituent Receivers, in ascending order of Typecode:
+of the constituent Receivers, in ascending order of Typecode:
 
 * :math:`\mathtt{typecode} : \mathtt{compactSize}` — the Typecode from the
   above Priority List;
@@ -464,7 +464,7 @@ The following FVK or IVK Encodings are used in place of the
 :math:`\mathtt{addr}` field:
 
 * An Orchard FVK or IVK Encoding, with Typecode :math:`\mathtt{0x03},` is
-  is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming
+  the raw encoding of the Orchard Full Viewing Key or Orchard Incoming
   Viewing Key respectively.
 
 * A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is the
@@ -694,7 +694,7 @@ Rationale for making Revision 0 UA/UVKs with MUST-understand Typecodes invalid
    Click to show/hide
 
 A Consumer implementing this ZIP prior to `Revision 1`_ will not
-recognize the Human-Readable Parts beginning with “``ur``” that mark a
+recognise the Human-Readable Parts beginning with “``ur``” that mark a
 `Revision 1`_ UA/UVK. So if a UA/UVK that includes MUST-understand
 Typecodes is required to use these `Revision 1`_ HRPs, this will ensure
 that the MUST-understand specification is correctly enforced even for
diff --git a/zip-0317.html b/zip-0317.html
index edd511c0..1ada72c0 100644
--- a/zip-0317.html
+++ b/zip-0317.html
@@ -10,7 +10,7 @@
         
    ZIP: 317
 Title: Proportional Transfer Fee Mechanism
 Owners: Aditya Bharadwaj <nighthawk24@gmail.com>
-        Daira Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Madars Virza
          Kris Nuttycombe
          Jack Grigg
@@ -25,7 +25,7 @@ Pull-Request: <https://githu
         
    Terminology 
    
             
    The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
             
    The term "conventional transaction fee" in this document is in reference to the value of a transaction fee that is conventionally used by wallets, and that a user can reasonably expect miners on the Zcash network to accept for including a transaction in a block.
    
-            
    The terms "Mainnet, "Testnet", and "zatoshi" in this document are defined as in 2.
    
+            
    The terms "Mainnet", "Testnet", and "zatoshi" in this document are defined as in 2.
    
         
    
         
    Abstract 
    
             
    The goal of this ZIP is to change the conventional fees for transactions by making them dependent on the number of inputs and outputs in a transaction, and to get buy-in for this change from wallet developers, miners and Zcash users.
    
diff --git a/zip-0317.rst b/zip-0317.rst
index 54dfce0e..4bb9986d 100644
--- a/zip-0317.rst
+++ b/zip-0317.rst
@@ -3,7 +3,7 @@
   ZIP: 317
   Title: Proportional Transfer Fee Mechanism
   Owners: Aditya Bharadwaj 
-          Daira Hopwood 
+          Daira-Emma Hopwood 
   Credits: Madars Virza
            Kris Nuttycombe
            Jack Grigg
@@ -29,7 +29,7 @@ to the value of a transaction fee that is conventionally used by wallets,
 and that a user can reasonably expect miners on the Zcash network to accept
 for including a transaction in a block.
 
-The terms "Mainnet, "Testnet", and "zatoshi" in this document are defined
+The terms "Mainnet", "Testnet", and "zatoshi" in this document are defined
 as in [#protocol-networks]_.
 
 
diff --git a/zip-0318.html b/zip-0318.html
index f60a9b25..1bf2b988 100644
--- a/zip-0318.html
+++ b/zip-0318.html
@@ -9,7 +9,7 @@
         
    ZIP: 318
 Title: Associated Payload Encryption
 Owners: Kris Nuttycombe <kris@electriccoin.co>
-        Daira Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Standards Track
 Created: 2022-09-19
diff --git a/zip-0318.rst b/zip-0318.rst
index a7d0c24a..02a3c3ab 100644
--- a/zip-0318.rst
+++ b/zip-0318.rst
@@ -3,7 +3,7 @@
   ZIP: 318
   Title: Associated Payload Encryption
   Owners: Kris Nuttycombe 
-          Daira Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Standards Track
   Created: 2022-09-19
diff --git a/zip-0319.html b/zip-0319.html
index 12088159..6d801d6b 100644
--- a/zip-0319.html
+++ b/zip-0319.html
@@ -9,7 +9,7 @@
         
    ZIP: 319
 Title: Options for Shielded Pool Retirement
 Owners: Nathan Wilcox <nathan@electriccoin.co>
-        Daira Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Informational
 Created: 2022-09-20
diff --git a/zip-0319.rst b/zip-0319.rst
index c5803436..da5134ec 100644
--- a/zip-0319.rst
+++ b/zip-0319.rst
@@ -3,7 +3,7 @@
   ZIP: 319
   Title: Options for Shielded Pool Retirement
   Owners: Nathan Wilcox 
-          Daira Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Informational
   Created: 2022-09-20
diff --git a/zip-0320.html b/zip-0320.html
index f076f63f..0094e011 100644
--- a/zip-0320.html
+++ b/zip-0320.html
@@ -9,10 +9,10 @@
     
    
         
    ZIP: 320
 Title: Defining an Address Type to which funds can only be sent from Transparent Addresses
-Owners: Daira-Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Kris Nuttycombe <kris@nutty.land>
 Credits: Hanh
-Status: Draft
+Status: Proposed
 Category: Standards / Wallet
 Created: 2024-01-12
 License: MIT
diff --git a/zip-0320.rst b/zip-0320.rst
index ebc5b5a6..19d4e496 100644
--- a/zip-0320.rst
+++ b/zip-0320.rst
@@ -2,7 +2,7 @@
 
   ZIP: 320
   Title: Defining an Address Type to which funds can only be sent from Transparent Addresses
-  Owners: Daira-Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Kris Nuttycombe 
   Credits: Hanh
   Status: Proposed
diff --git a/zip-0321.html b/zip-0321.html
index 66f25410..447bcf50 100644
--- a/zip-0321.html
+++ b/zip-0321.html
@@ -8,8 +8,8 @@
     
    
         
    ZIP: 321
 Title: Payment Request URIs
-Owners: Kris Nuttycombe (kris@electriccoin.co)
-        Daira Emma Hopwood (daira@electriccoin.co)
+Owners: Kris Nuttycombe <kris@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Credits: Francisco Gindre
 Status: Proposed
 Category: Standards / Wallet
diff --git a/zip-0321.rst b/zip-0321.rst
index 14f4e7ac..42f0be20 100644
--- a/zip-0321.rst
+++ b/zip-0321.rst
@@ -2,8 +2,8 @@
 
   ZIP: 321
   Title: Payment Request URIs
-  Owners: Kris Nuttycombe (kris@electriccoin.co)
-          Daira Emma Hopwood (daira@electriccoin.co)
+  Owners: Kris Nuttycombe 
+          Daira-Emma Hopwood 
   Credits: Francisco Gindre
   Status: Proposed
   Category: Standards / Wallet
diff --git a/zip-0322.html b/zip-0322.html
index f40d997c..9ad8f3dc 100644
--- a/zip-0322.html
+++ b/zip-0322.html
@@ -9,7 +9,7 @@
         
    ZIP: 322
 Title: Generic Signed Message Format
 Owners: Jack Grigg <jack@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Standards / RPC / Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/429>
    
diff --git a/zip-0322.rst b/zip-0322.rst
index a1b26ef4..adc37295 100644
--- a/zip-0322.rst
+++ b/zip-0322.rst
@@ -3,7 +3,7 @@
   ZIP: 322
   Title: Generic Signed Message Format
   Owners: Jack Grigg 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Standards / RPC / Wallet
   Discussions-To: 
diff --git a/zip-0323.html b/zip-0323.html
index d8bff541..0fa4f538 100644
--- a/zip-0323.html
+++ b/zip-0323.html
@@ -8,7 +8,7 @@
     
    
         
    ZIP: 323
 Title: Specification of getblocktemplate for Zcash
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
 Status: Reserved
 Category: RPC / Mining
diff --git a/zip-0323.rst b/zip-0323.rst
index fa33921b..5e5465e6 100644
--- a/zip-0323.rst
+++ b/zip-0323.rst
@@ -2,7 +2,7 @@
 
   ZIP: 323
   Title: Specification of getblocktemplate for Zcash
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
   Status: Reserved
   Category: RPC / Mining
diff --git a/zip-0324.html b/zip-0324.html
index ac47076a..2816bce7 100644
--- a/zip-0324.html
+++ b/zip-0324.html
@@ -3,6 +3,7 @@
 
     ZIP 324: URI-Encapsulated Payments
     
+    
 
 
     
    
@@ -25,16 +26,16 @@ Status: Draft
 Category: Standards / Wallet
 Created: 2019-07-17
 License: MIT
    
-        
    Terminology 
    
+        
    Terminology 
    
             
    The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
    
             
    Zcash protocol terms are as defined in the Zcash Protocol Specification. 3
    
             
         
    
-        
    Abstract 
    
+        
    Abstract 
    
             
    This proposal specifies a mechanism for sending Zcash payments via any unmodified (secure) messaging service, e.g., Signal or WhatsApp. The sender need not know the recipient's address and the recipient need not have a Zcash wallet already installed. Payments occur via an ordinary text/WhatsApp/Signal message containing a URI. The URI encodes the secret spending key of an ephemeral Zcash “wallet address”, to which the funds have been transferred. Anyone who learns the URI can accept this payment, by a “finalization” process which uses the key given in the URI to transfer the encapsulated funds to their own wallet. After the payment is finalized, via a suitable on-chain transaction by the recipient, it becomes irrevocable.
    
             
    The proposal specifies the syntax and semantics of URI-Encapsulated Payments, the workflow of generating and handling them, and requisite infrastructure.
    
             
    At its core, a URI encapsulated payment communicates the existence of a transaction (specifically a note committing to an amount of funds) to a receiving client. The URI encodes the amount of the payment and a key used to derive all necessary randomness for note construction including the address and secret key needed to spend it.
    
-            
    Usage Story 
    
+            
    Usage Story 
    
                 
    Alice wants to send a 1.23 ZEC payment to Bob. She doesn't have Bob's Zcash address — and Bob may not even have a wallet or have heard of Zcash! However, she does have some end-to-end encrypted channel to Bob on a secure messaging app, such as Signal or WhatsApp. She instructs her own Zcash wallet to send 1.23 ZEC on that channel. Her wallet then automatically generates a new ephemeral Zcash address and sends 1.23001 ZEC to this address. It then constructs a payment URI containing the secret key corresponding to the ephemeral address, and sends it to Bob via the secure messaging app.
    
                 
    Bob receives the message, which looks as follows:
    
                 
    
@@ -45,7 +46,7 @@ License: MIT
    
                 
    Bob clicks the link. His Zcash mobile wallet app (which is already installed and has configured itself as a handler for URLs of that form) shows up, and tells Bob that a payment of 1.23 ZEC awaits him. The wallet app confirms the existence of the pertinent transactions on the blockchain, and then offers to finalize the payment. Bob clicks the “Finalize” button, and his wallet app generates a transaction moving the money to his own address (using the extra 0.00001 ZEC he has received to pay the transaction fee). When this transaction is confirmed on-chain, Alice's and Bob's wallets both indicate that the payment is finalized, and thus Bob can send the funds to other parties.
    
             
    
         
    
-        
    Motivation 
    
+        
    Motivation 
    
             
    This proposal enables sending of funds without exposing users to the notion of payment addresses and their secure distribution. Instead, funds can be sent using any pre-existing communication channel, by a single message sent unidirectionally from the sender to the recipient. This message conveys all the information needed to obtain control of the funds, compactly expressed as a textual URI.
    
             
    Consequently, all functionality related to contact discovery and secure-channel establishment can be delegated to the message app(s) with which the user is already familiar, and in which the user has already established communication channels to many of their contacts.
    
             
    Moreover, funds can be sent to users who have not yet installed wallet software and who do not yet have a payment address. The recipient can collect the funds at any later time by installing suitable software.
    
@@ -53,7 +54,7 @@ License: MIT
    
             
    Finally, this avoids the fat-finger problem of sending funds to the wrong address. The user sends funds via a known contact on, e.g., WhatsApp, who they have a relationship with or at least can confirm the recipient's identity. Moreover, even once funds are sent via a URI, they can be recovered if the other party does not claim them.
    
             
    The proposal is complementary to ZIP 321 4, which will standardize Payment Request URIs using which the payment recipient can convey their persistent payment address to the sender, for subsequent fund transfers (to be done using the normal on-chain mechanism rather than the encapsulated payments described in the current proposal).
    
         
    
-        
    Requirements 
    
+        
    Requirements 
    
             
    This proposal's specification of URI-Encapsulated Payments, and the intended protocols for using them, is meant to fulfill the following requirements:
    
             
      
                 
    • The protocol must not require the sender of a payment to stay online until the recipient receives the URI (let alone finalizes the payment).
      • 
@@ -66,15 +67,15 @@ License: MIT
    
                 
  • Don't lose funds, even if wallets crash, or everything but the sending wallet master secret is lost.
    • 
             
         
-        
    Non-requirements 
    
+        
    Non-requirements 
    
             
      
                 
    • It is outside the scope of this proposal to establish a secure communication channel for transmission of URI-Encapsulated Payments, or to protect the parties' devices from security compromise.
      • 
                 
    • Finalizing the payment may involve significant wait times, on the scale of minutes, as the requisite on-chain transactions are generated, mined and confirmed. This proposal does not try to solve this (though it does try to avoid imposing significant additional delays, and it does address how the intermediate state is conveyed to the user).
      • 
             
    
         
    
-        
    Specification 
    
+        
    Specification 
    
             
    A Payment-Encapsulating URI represents the capability to claim the Zcash funds from specific on-chain transactions, as long as they're unspent. See Usage Story for an example.
    
-            
    Syntax 
    
+            
    Syntax 
    
                 
    A Payment-Encapsulating URI is a Universal Resource Locator (URL), as defined in RFC 3986 2, of the following form.
    
                 
    Scheme: https
    
                 
    Host: pay.withzcash.com
    
@@ -87,7 +88,7 @@ License: MIT
                     
  • key= is a 256-bit random number encoded with Bech32 as specified in Section 5.6.9 of the Zcash Protocol Specification 3). MUST be present.
    • 
                 
             
    
-            
    Semantics 
    
+            
    Semantics 
    
                 
    The values of key and amount deterministically imply a unique payment note corresponding to this URI, which is a Zcash Sapling note that carries the given amount and is spendable by a Sapling spending key derived from key. The derivation of this note is done by the following procedure:
    
                 
    DerivePaymentNote(key,amount):
    
                 
      
@@ -119,7 +120,7 @@ License: MIT
                 
      The recipient's wallet software SHOULD convey to the user that the desc value is merely a claim made by the party who sent the URI, and may be tentative, inaccurate or malicious.
      
                 
      In particular, the recipient's wallet software SHOULD convey to the user that the amount of ZEC they can successfully transfer to their wallet may be different than that given by the amount parameter, and may change (possibly to zero), until the finalization process has been completed.
      
             
    
-            
    Centralized Deployment 
    
+            
    Centralized Deployment 
    
                 
    The owner of the withzcash.com domain name MUST NOT create a DNS record for the pay.withzcash.com domain name, nor a TLS certificate for it. All feasible means SHOULD be taken to ensure this, and to prevent unintended transfer of ownership or control over the withzcash.com domain name. (See Rationale for URI Format and Security Considerations below for discussion.)
    
                 
    Applink mechanisms let domain name owners provide a whitelist, specifying which apps are authorized to handle URLs with that domain name. This is implemented by serving suitable files at well-known paths on the web server of that domain or, in the case of a subdomain, its parent domain. Thus, the owner of the withzcash.com domain effectively controls the whitelist of apps that may be launched by users' platform to handle URI-Encapsulated Payments (see Security Considerations). This whitelist should protect users from installing rogue apps that intercept incoming payments. Thus, the domain owner MUST do the following:
    
                 
      
@@ -136,17 +137,17 @@ License: MIT
                     
    • Strive for the whitelist to include all apps that would not place the user at any greater security risk than reputable state-of-the-art wallet apps.
      • 
                 
    
             
    
-            
    Testing 
    
+            
    Testing 
    
                 
    For testing purposes, all of the above specification is duplicated for the Zcash testnet network, substituting TAZ (Zcash testnet coins) for ZEC and testzcash.com for withzcash.com.
    
                 
    A separate “testnet whitelist” MUST be maintained by the owner of the testzcash.com domain name, with a separate policy that SHOULD allow any legitimate third-party developer to add their work-in-progress wallet for testing purposes. Integrity and availability MAY be looser.
    
                 
    Wallets apps MAY support just one type of payments (ZEC or TAZ), and if they support both then they MUST keep separate accounting and must clearly distinguish the type when payments or balances are conveyed to users.
    
             
    
         
    
-        
    Lifecycle Specification 
    
+        
    Lifecycle Specification 
    
             
    The lifecycle of a Payment-Encapsulating URI consists of several stages, which in the usual case culminate in the funds being irrevocably deposited into the recipient's personal wallet irrevocably:
    
-            
    Generating the notes and URI 
    
+            
    Generating the notes and URI 
    
                 
    The sender's Zcash wallet app creates an ephemeral spending key, sends ZEC funds to the payment addressed derived from that key, and creates a Payment-Encapsulating URI that contains this ephemeral spending key and the newly-generated note commitments.
    
-                
    Ephemeral key derivation 
    
+                
    Ephemeral key derivation 
    
                     
    The ephemeral keys within payment URIs are derived deterministically from the same seed as the main wallet. This ensures that if a wallet is recovered from backup, sent-but-unfinalized payments can be reclaimed.
    
                     
    The derivation mechanism is as follows:
    
                     
      
@@ -159,17 +160,17 @@ License: MIT
                     
    
                 
    
             
    
-            
    URI Transmission 
    
+            
    URI Transmission 
    
                 
    The sender conveys the Payment-Encapsulating URI to the intended recipient, over some secure channel (e.g., an end-to-end encrypted messaging platform such as Signal, WhatsApp or Magic Wormhole; or a QR code scanned in person).
    
                 
    If transmitted via a human-readable medium, such as a messaging app, the Payment-Encapsulating URI MAY be accompanied by a contextual explanation that the URI encapsulates a payment, and a suggested action by the recipient to complete the process (see Usage Story above for an example).
    
                 
    When sent via a human-readable medium that consists of discrete messages, the message that contains the URI SHOULD NOT contain any payment-specific or manually-entered information outside the URI itself, since this information may not be visible to the recipient (see “Message Rendering” below).
    
                 
    From this point, and until finalization or cancellation (see below), from the sender's perspective the payment is “in progress”; it SHOULD be conveyed as such to the sender; and MUST NOT be conveyed as “finalized” or other phrasing that conveys successful completion.
    
             
    
-            
    Message Rendering 
    
+            
    Message Rendering 
    
                 
    The recipient's device renders the Payment-Encapsulating URI, or an indication of its arrival, along with the aforementioned contextual explanation (if any). The user has the option of “opening” the URI (i.e., by clicking it), which results in the device opening a Zcash wallet app, using the local platforms app link mechanism.
    
                 
    A messaging app MAY recognize URI-Encapsulated Payments, and render them in a way that conveys their nature more clearly than raw URI strings. If the messaging medium consists of discrete messages, and a message contains one or more URI-Encapsulated Payments, then the messaging app MAY assume that all other content in that message is automatically generated and contains no payment-specific or manually-generated information, and thus may be discarded during rendering.
    
             
    
-            
    Payment Rendering and Blockchain Lookup 
    
+            
    Payment Rendering and Blockchain Lookup 
    
                 
    The recipient's Zcash wallet app SHOULD present the payment amount and MAY present the description, as conveyed in the URI, along with an indication of the tentative nature of this information.
    
                 
    In parallel, the wallet app SHOULD retrieve the relevant transactions from the Zcash blockchain, by looking up the transaction given by the cmu parameter (this MAY use an efficient index, perhaps assisted by a server), and check whether:
    
                 
      
@@ -186,22 +187,22 @@ License: MIT
                 
      Within the Pending state, the wallet app MAY also consider “0 confirmations” transactions (i.e., transactions that have been broadcast on the node network but are neither mined nor expired), and convey their existence to the user. These do not suffice for entering the Ready-to-finalize state (since unmined notes cannot be immediately spent.)
      
                 
      The aforementioned conditions may change over time (e.g., the transactions may be spent by someone else in the interim), so the status SHOULD be updated periodically.
      
             
    
-            
    Finalization 
    
+            
    Finalization 
    
                 
    When the recipient chooses to finalize the payment, the wallet app generates transactions that spends the aforementioned notes (using the ephemeral spending key) and send these Zcash funds to the user's own persistent payment address. These transactions carry the default expiry time (currently 100 blocks).
    
                 
    The recipient's wallet app SHOULD convey the payment status as “Finalizing…” starting at the time that the uses initiates the finalization process. It MAY in addition convey the specific action done or event waited.
    
                 
    The sender's wallet SHOULD convey the payment status as “Finalizing…” as soon as it detects that relevant transactions have been broadcast on the peer-to-peer network, or mined to the blockchain.
    
                 
    Once these transactions are confirmed (to an extent considered satisfactory by the local wallet app; currently 10 confirmations is common practice), their status SHOULD be conveyed as “Finalized”, by both the sender's wallet app and the recipient's wallet app. Both wallets MUST NOT convey the payment as “finalized”, or other phrasing that conveys irrevocability, until this point.
    
                 
    If these transactions expire unmined, or are otherwise rendered irrevocably invalidated (e.g., by a rollback), then both wallets' status SHOULD convey this, and the recipient's wallet SHOULD revert to the “Payment Rendering and Blockchain Lookup” stage above.
    
             
    
-            
    Payment Cancellation 
    
+            
    Payment Cancellation 
    
                 
    At any time prior to the payment being finalized, the sender is capable of cancelling the payment, by themselves finalizing the payment into their own wallet (thereby “clawing back” the funds). If the wallet has not yet sent, for inclusion in the blockchain, any of the transactions associated with the ephemeral spending key, then cancellation can also be done by discarding these transactions or aborting their generation. The sender's wallet app SHOULD offer this feature, and in this case, MUST appropriately handle the race condition where the recipient initiated finalization concurrently.
    
                 
    Cancellation requires the sender to know the ephemeral spending key. If the sender has lost this state, it can be recovered deterministically (see Recovery From Wallet Crash, below).
    
             
    
-            
    Status View 
    
+            
    Status View 
    
                 
    Wallet apps SHOULD let the user view the status of all payments they have generated, as well as all inbound payment (i.e., URI-Encapsulated Payments that have been sent to the app, e.g., by invocation from messaging apps). The status includes the available metadata, and the payment's current state. When pertinent, the wallet app SHOULD offer the ability to finalize any Pending inbound payment, and MAY offer the ability to cancel any outbound payment.
    
                 
    Wallet apps SHOULD actively alert the user (e.g., via status notifications) if a payment that they sent has not been finalized within a reasonable time period (e.g., 1 week), and offer to cancel the payment.
    
             
    
-            
    Recovery From Wallet Crash 
    
+            
    Recovery From Wallet Crash 
    
                 
    When recovering from a backed-up wallet phrase, wallet implementations already need to scan the entire chain (from the wallet's birthday) to find transactions that were received by or sent from the wallet. Simultaneously with this, the wallet may recover state about previously-created payment URIs, and regain access to non-finalized funds.
    
                 
    We define a “gap limit” N, similar to the “address gap limit” in BIP 44. If a wallet implementation observes N sequentially-derived payment URIs that have no corresponding on-chain note, they may safely expect that no payment URIs beyond that point have ever been derived.
    
                 
    Given that both the derivation of a payment URI and the action of “filling” it with a note are performed by the same entity (and in most cases sequentially), it is unlikely that there would be a significantly large gap in payment URI usage. As a balance between the cost of scanning multiple ivks, and the likelihood of missing on-chain funds due to out-of-order payment URI generation, we specify a standard gap limit of N = 3.
    
@@ -222,7 +223,7 @@ License: MIT
                 
    For this recovery process to succeed, wallet implementations MUST fund payment URIs with a Sapling spending key in the wallet. Alternatively, wallet implementations MAY include the set of payment URI ivks within the set of ivks they are using for normal chain scanning, but this will slow down the recovery process by a factor of 4 (for a gap limit of N = 3, and a wallet with one Sapling account).
    
             
    
         
    
-        
    Security Considerations 
    
+        
    Security Considerations 
    
             
      
                 
    • Anyone who intercepts the URI-Encapsulated Payments may steal the encapsulated funds. Therefore, URI-Encapsulated Payments should be sent over a secure channel, and should be kept secret from anyone but the intended recipient.
                     
        
@@ -244,8 +245,8 @@ License: MIT
                 
      • Usage of URI-Encapsulated Payments may train users to, generally, click on other types of URI/URL links sent in other messaging contexts. Malicious links sent via unauthenticated messaging channels (e.g., emails and SMS texts) are a common attack vector, used for exploiting vulnerabilities in the apps triggered to handle these links. Even though the fault for vulnerabilities lies with those other apps, and even though this ZIP uses deep link URIs in the way intended, there are none the less these negative externalities to encouraging such use.
        • 
             
      
         
    
-        
    Design Decisions and Rationale 
    
-            
    Rationale for URI Format 
    
+        
    Design Decisions and Rationale 
    
+            
    Rationale for URI Format 
    
                 
    The URI format https://pay.withzcash.com:65536/v1#... was chosen to allow automatic triggering of wallet software on mobile devices, using the platform's applink mechanism, while minimizing the risk of payment information being intercepted by third parties. The latter is prevented by a defense in depth, where any of the following suffices to prevent the payment information from being exposed over the network:
    
                 
      
                     
    • The pay.withzcash.com domain should not resolve.
      • 
@@ -263,24 +264,22 @@ License: MIT
                 
                 
      Another option, which can be added to any of the above, is to add a confirmation code outside the URI that needs to be manually entered by the user into the wallet app, so that merely intercepting the URI link would not suffice. This does not seem to significantly reduce risk in the scenarios considered, and so deemed to not justify the reduced usability.
      
             
    
-            
    Identifying Notes 
    
+            
    Identifying Notes 
    
                 
    The recipient's wallet needs to identify the notes related to the payment (and the on-chain transactions that contain them), in order to verify their validity and then (during the finalization process) spend them.
    
                 
    The following is out of date, and reflects an earlier design choice (“0”), while we have transitioned to a different choice (“4”). To be revised.
    
                 
    In the above description, we explicitly list the notes involved in the payment (which are easily mapped to the transactions containing them, using a suitable index). This results in long URIs when multiple notes are involved (e.g., when using the aforementioned “powers-of-2 amounts” technique).
    
                 
    Instead, we can have the nodes be implicitly identified by the spending key (or similar) included in the URI. This can make URI shorter, thus less scary and less likely to run into length limits (consider SMS). The following alternatives are feasible:
    
+                
    
+                    \(\hspace{0.9em}\)
+                0. Explicitly list the note commitments within the URI.
    
                 
      
-                    
    1. Explicitly list the note commitments within the URI.
      2. 
                     
    2. Include only the spending key(s) in the URI, and have the recipient scan the blockchain using the existing mechanism (trial decryption of the encrypted memo field). This is very slow, and risks denial-of-service attacks. Would be faster in the nominal case if the scanning is done backwards (newest block first), or if told by the sender when the transactions were mined; but scanning the whole chain for nonexistent transactions (perhaps induced by a DoS) would still take very long.
      3. 
                     
    3. Derive a tag from a seed included in the URI, and put this tag within the encrypted memo field of the output descriptors in the associated transactions. Put the tag plaintext within the space reserved for the memo field ciphertext (breaking the AEAD abstraction). The recipient's wallet (or the service assisting it) would maintain an index of such tags, and efficiently look up the tags derived from the URI. The tags are publicly-visible and thus may leak information on the payment amount (e.g., when using the powers-of-2 pre-generation technique).
      4. 
                     
    4. Similarly to the above, but place the tag in an additional zero-value output descriptor added to each pertinent transaction. The recipient can recompute this note commitment and use that as the identifier, to be looked up in an index in order to locate the transaction. Here too, the tags are publicly-visible and thus may leak information on the payment amount (e.g., when using the powers-of-2 pre-generation technique).
      5. 
                     
    5. Have the URI include a seed and the amount of the (single) output note. Let the seed determine not only the spending key, but also all randomness involved in the generation of the note. Thus, the recipient can deterministically derive the note commitment from the seed and amount, and look it up to find the relevant transaction. This requires the recipient (or the server assisting them) to maintain an index mapping note commitments (of output descriptors that are the first in their transaction) to the transaction that contains them. Additional notes can be included in the same transaction.
      6. 
                 
    
-                
    
-                    
    System Message: INFO/1 (zip-0324.rst line 355)
    
-                    
    Enumerated list start value not ordinal-1: "0" (ordinal 0)
    
-                
    
             
    
-            
    Additional rationale 
    
+            
    Additional rationale 
    
                 
      
                     
    1. The metadata (amount and description) is provided within the URI. An alternative would be to encode the description in the encrypted memo fields of the associated shielded transactions, and compute the amount from those transactions. However, in that case the metadata would not be available for presentation to the user until the transactions have been retrieved from the blockchain.
      2. 
                     
    2. We support multiple spending keys and multiple notes in one URI, because these payments may be speculatively generated and mined before the payment amount is determined (to allow payments with no latency). For example, the sending wallets may pre-generate transactions for powers-of-2 amounts, and then include only a subset of them in the URI, totalling to the desired amount.
      3. 
@@ -288,8 +287,8 @@ License: MIT
                 
    
             
    
         
    
-        
    Open Questions 
    
-            
    URI Usability 
    
+        
    Open Questions 
    
+            
    URI Usability 
    
                 
    The URI could be changed in several ways due to usability concerns:
    
                 
      
                     
    1. It may be desirable to prevent the amount and desc parameters from being human readable. This is to discourage people from just looking at the URI, seeing the numbers and text, and mistakenly thinking this is already a confirmation of successful receipt (without going through the finalization process).
      2. 
@@ -302,15 +301,15 @@ License: MIT
                     
                 
    
             
    
-            
    Note retrieval 
    
+            
    Note retrieval 
    
                 
    Ideally: a lightweight wallet can receive the funds with the assistance of a more powerful node, with minimal information leakage to that node (e.g., using simple lookups queries that can be implemented via Private Information Retrieval). The open question is how to do this given that most practical PIR are for retrieving an index out of an array, not a key from a key value standpoint.
    
             
    
-            
    Other Questions 
    
+            
    Other Questions 
    
                 
    Should senders delay admitting a generated transaction by a random amount to prevent traffic analysis (i.e., so the messaging service operator cannot correlate messages with on-chain transactions)?
    
                 
    Consider the behavior in case a chain reorgs invalidates a sent payment. Should we specify a Merkle root or block hash to help detect this reason for payment failure? Or have some servers that maintain a cache of payments that were invalidated by reorgs?
    
             
    
         
    
-        
    References 
    
+        
    References 
    
             
    
@@ -376,7 +375,7 @@ License: MIT
    
                 
                     
    
                 
    
             
    
         
    
-        
    Publication Blockers 
    
+        
    Publication Blockers 
    
             
      
                 
    • Clean up semantics.
      • 
                 
    • Clean up rationale.
      • 
diff --git a/zip-0324.rst b/zip-0324.rst
index 60688e08..93f861e5 100644
--- a/zip-0324.rst
+++ b/zip-0324.rst
@@ -386,7 +386,7 @@ In the above description, we explicitly list the notes involved in the payment (
 
 Instead, we can have the nodes be implicitly identified by the spending key (or similar) included in the URI. This can make URI shorter, thus less scary and less likely to run into length limits (consider SMS). The following alternatives are feasible:
 
-0. Explicitly list the note commitments within the URI.
+:math:`\hspace{0.9em}`\0. Explicitly list the note commitments within the URI.
 
 1. Include only the spending key(s) in the URI, and have the recipient scan the blockchain using the existing mechanism (trial decryption of the encrypted memo field). This is very slow, and risks denial-of-service attacks. Would be faster in the nominal case if the scanning is done backwards (newest block first), or if told by the sender when the transactions were mined; but scanning the whole chain for nonexistent transactions (perhaps induced by a DoS) would still take very long.
 
diff --git a/zip-0332.html b/zip-0332.html
index d016de12..60c742bd 100644
--- a/zip-0332.html
+++ b/zip-0332.html
@@ -9,7 +9,7 @@
         
      ZIP: 332
 Title: Wallet Recovery from zcashd HD Seeds
 Owners: Kris Nuttycombe <kris@electriccoin.co>
-        Daira Emma Hopwood <daira@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/675>
      
diff --git a/zip-0332.rst b/zip-0332.rst
index 81b2d27b..27ee7e63 100644
--- a/zip-0332.rst
+++ b/zip-0332.rst
@@ -3,7 +3,7 @@
   ZIP: 332
   Title: Wallet Recovery from zcashd HD Seeds
   Owners: Kris Nuttycombe 
-          Daira Emma Hopwood 
+          Daira-Emma Hopwood 
   Status: Reserved
   Category: Wallet
   Discussions-To: 
diff --git a/zip-0339.html b/zip-0339.html
index 59868505..ff429762 100644
--- a/zip-0339.html
+++ b/zip-0339.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 339
 Title: Wallet Recovery Words
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Reserved
 Category: Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/364>
      
diff --git a/zip-0339.rst b/zip-0339.rst
index 91ac9df9..aa1cb8bc 100644
--- a/zip-0339.rst
+++ b/zip-0339.rst
@@ -2,7 +2,7 @@
 
   ZIP: 339
   Title: Wallet Recovery Words
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Reserved
   Category: Wallet
   Discussions-To: 
diff --git a/zip-0401.html b/zip-0401.html
index 9061762f..aaec293e 100644
--- a/zip-0401.html
+++ b/zip-0401.html
@@ -9,7 +9,7 @@
     
      
         
      ZIP: 401
 Title: Addressing Mempool Denial-of-Service
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
 Status: Active
 Category: Network
 Created: 2019-09-09
diff --git a/zip-0401.rst b/zip-0401.rst
index 49521c62..e319996a 100644
--- a/zip-0401.rst
+++ b/zip-0401.rst
@@ -2,7 +2,7 @@
 
   ZIP: 401
   Title: Addressing Mempool Denial-of-Service
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
   Status: Active
   Category: Network
   Created: 2019-09-09
diff --git a/zip-0416.html b/zip-0416.html
index afc4201b..00519ad2 100644
--- a/zip-0416.html
+++ b/zip-0416.html
@@ -8,7 +8,7 @@
     
      
         
      ZIP: 416
 Title: Support for Unified Addresses in zcashd
-Owners: Daira Emma Hopwood <daira@electriccoin.co>
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
         Jack Grigg <jack@electriccoin.co>
         Sean Bowe <sean@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
diff --git a/zip-0416.rst b/zip-0416.rst
index eb435a1c..f8ccc691 100644
--- a/zip-0416.rst
+++ b/zip-0416.rst
@@ -2,7 +2,7 @@
 
   ZIP: 416
   Title: Support for Unified Addresses in zcashd
-  Owners: Daira Emma Hopwood 
+  Owners: Daira-Emma Hopwood 
           Jack Grigg 
           Sean Bowe 
           Kris Nuttycombe 
diff --git a/zip-1010.html b/zip-1010.html
index 707f57cf..222d6b12 100644
--- a/zip-1010.html
+++ b/zip-1010.html
@@ -167,7 +167,7 @@ Discussions-To: <ZF Grants — Funding for Zcash ecosystem projects
+                        ZF Grants — Funding for Zcash ecosystem projects
                     
                 
             
diff --git a/zip-1010.rst b/zip-1010.rst
index a5b65d82..95f41ac0 100644
--- a/zip-1010.rst
+++ b/zip-1010.rst
@@ -348,7 +348,7 @@ References
 .. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. `_
 .. [#tromer-comment] `Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019. `_
 .. [#restricted-funds] `“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018. `_
-.. [#zfnd-grants] `ZF Grants — Funding for Zcash ecosystem projects `_
+.. [#zfnd-grants] `ZF Grants — Funding for Zcash ecosystem projects `_
 .. [#zfnd-state] `The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. `_
 .. [#acityinohio-comment] `Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019. `_
 .. [#zip-1007] `ZIP 1007: Enforce Development Fund Commitments with a Legal Charter `_
diff --git a/zip-1014.html b/zip-1014.html
index bd2dcbf1..570b3d49 100644
--- a/zip-1014.html
+++ b/zip-1014.html
@@ -14,7 +14,7 @@ Original-Authors: Eran Tromer
 Credits: Matt Luongo
          @aristarchus
          @dontbeevil
-         Daira Emma Hopwood
+         Daira-Emma Hopwood
          George Tankersley
          Josh Cincinnati
          Andrew Miller
diff --git a/zip-1014.rst b/zip-1014.rst
index 8b668482..f6934e1f 100644
--- a/zip-1014.rst
+++ b/zip-1014.rst
@@ -8,7 +8,7 @@
   Credits: Matt Luongo
            @aristarchus
            @dontbeevil
-           Daira Emma Hopwood
+           Daira-Emma Hopwood
            George Tankersley
            Josh Cincinnati
            Andrew Miller
diff --git a/zip-guide-markdown.html b/zip-guide-markdown.html
new file mode 100644
index 00000000..e1b2b280
--- /dev/null
+++ b/zip-guide-markdown.html
@@ -0,0 +1,254 @@
+
+
+
+    ZIP guide-markdown: {Something Short and To the Point}
+    
+    
+    
+
+
+
      ZIP: Unassigned {numbers are assigned by ZIP editors}
+Title: {Something Short and To the Point}
+Owners: First Owner <email>
+        ...
+Credits: First Credited
+         ...
+Status: Draft
+Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational | Process}
+Created: yyyy-mm-dd
+License: {usually MIT}
+Pull-Request: <https://github.com/zcash/zips/pull/???>
      
+
      Don’t Panic
      
+
      If this is your first time writing a ZIP, the structure and format
+may look intimidating. But really, it’s just meant to reflect
+common-sense practice and some technical conventions. Feel free to start
+with a simple initial draft that gets ideas across, even if it doesn’t
+quite follow this format. The community and ZIP editors will help you
+figure things out and get it into shape later.
      
+
      {Delete this section.}
      
+
      Terminology
      
+
      {Edit this to reflect the key words that are actually used.} The key
+words “MUST”, “REQUIRED”, “MUST NOT”, “SHOULD”, and “MAY” in this
+document are to be interpreted as described in BCP 14 1
+when, and only when, they appear in all capitals.
      
+
      {Avoid duplicating definitions from other ZIPs. Instead use wording
+like this:}
      
+
      The terms “Mainnet” and “Testnet” in this document are to be
+interpreted as defined in the Zcash protocol specification 2.
      
+
      The term “full validator” in this document is to be interpreted as
+defined in the Zcash protocol specification 3.
      
+
      The terms below are to be interpreted as follows:
      
+
      
+
      {Term to be defined}
      
+
      
+
      {Definition.}
      
+
      
+
      {Another term}
      
+
      
+
      {Definition.}
      
+
      
+
      
+
      Abstract
      
+
      {Describe what this proposal does, typically in a few paragraphs.
      
+
      The Abstract should only provide a summary of the ZIP; the ZIP should
+remain complete without the Abstract.
      
+
      Use links where applicable, e.g. 4 5.}
      
+
      Motivation
      
+
      {Why is this proposal needed?
      
+
      This is one of the most important sections of the ZIP, and should be
+detailed and comprehensive. It shouldn’t include any of the actual
+specification – don’t put conformance requirements in this section.
      
+
      Explain the status quo, why the status quo is in need of improvement,
+and if applicable, the history of how this area has changed. Then
+describe at a high level why this proposed solution addresses
+the perceived issues. It is ok if this is somewhat redundant with the
+abstract, but here you can go into a lot more detail.}
      
+
      Requirements
      
+
      {Describe design constraints on, or goals for the solution –
+typically one paragraph for each constraint or goal. Again, don’t
+actually specify anything here; this section is primarily for use as a
+consistency check that what is specified meets the requirements.}
      
+
      Non-requirements
      
+
      {This section is entirely optional. If it is present, it describes
+issues that the proposal is not attempting to address, that
+someone might otherwise think it does or should.}
      
+
      Specification
      
+
      {Replace this entire section.}
      
+
      The Specification section describes what should change, using precise
+language and conformance key words. Anything that is required in
+order to implement the ZIP (or follow its process, in the case of a
+Process ZIP) should be in this section.
      
+
      Avoid overspecification! Also avoid underspecification. Specification
+is hard. Don’t be afraid to ask for help.
      
+
      Feel free to copy from other ZIPs doing similar things, e.g. defining
+RPC calls, consensus rules, etc.
      
+
      ZIPs MUST take into account differences between the Zcash Mainnet and
+Testnet 6 where applicable. A consensus ZIP
+MUST be able to be deployed on both Mainnet and Testnet.
      
+
      Unless the specification is particularly simple, you will need to
+organise it under subheadings.
      
+
      Example subheading
      
+
      At least while the ZIP is in Draft, we encourage writing open
+questions and TODOs.
      
+
      Open questions
      
+
        
+
      • What happens if a full validator can’t parse the fandangle as a
+doohicky?
        • 
+
      
+
      TODO: define byte encoding for the Jabberwock.
      
+
      Comparison of ZIPs to RFCs
      
+
      Like RFCs, ZIPs are precise technical documents that SHOULD give
+enough implementation information to implement part of a Zcash-related
+protocol or follow a Zcash-related process 7.
      
+
      ZIPs are different from RFCs in the following ways:
      
+
        
+
      • Many (but not all) ZIPs are “living documents”; they are updated
+in-place as the relevant areas of the protocol or process change. Unlike
+in the RFC process, making a change in an area described by a published
+ZIP does not necessarily require creating a new ZIP, although
+that is an option if the change is extensive enough to warrant it.
        • 
+
      • The expected structure of a ZIP is more constrained than an RFC. For
+example, the Specification section is REQUIRED, and all of the
+conformance requirements MUST go in that section. The ZIP editors will
+help you to ensure that things go in the right sections.
        • 
+
      • Security considerations SHOULD be spread throughout the text, in the
+places where they are most relevant.
        • 
+
      
+
      Using mathematical notation
      
+
      Embedded LaTeX x + y is allowed and
+encouraged in ZIPs. The syntax for inline math is
+“:math:latex
+code`" in reStructuredText or "latexcode`”
+in Markdown. The rendered HTML will use KaTeX 8,
+which only supports a subset of LaTeX, so you will need to double-check
+that the rendering is as intended.
      
+
      In general the conventions in the Zcash protocol specification SHOULD
+be followed. If you find this difficult, don’t worry too much about it
+in initial drafts; the ZIP editors will catch any inconsistencies in
+review.
      
+
      Notes and warnings
      
+
      
+
      “.. note::” in reStructuredText, or
+“:::info” (terminated by “:::”) in Markdown,
+can be used for an aside from the main text.
      
+
      The rendering of notes is colourful and may be distracting, so they
+should only be used for important points.
      
+
      
+
      
+
      “.. warning::” in reStructuredText, or
+“:::warning” (terminated by “:::”) in
+Markdown, can be used for warnings.
      
+
      Warnings should be used very sparingly — for example to signal that a
+entire specification, or part of it, may be inapplicable or could cause
+significant interoperability or security problems. In most cases, a
+“MUST” or “SHOULD” conformance requirement is more appropriate.
      
+
      
+
      Valid markup
      
+
      This is optional before publishing a PR, but to check whether a
+document is valid reStructuredText or Markdown, first install
+rst2html5 and pandoc. E.g. on Debian-based
+distros::
      
+
      sudo apt install python3-pip pandoc perl sed
+pip3 install docutils==0.19 rst2html5
      
+
      Then, with draft-myzip.rst or
+draft-myzip.md in the root directory of a clone of this
+repo, run::
      
+
      make draft-myzip.html
      
+
      (or just “make”) and view draft-myzip.html
+in a web browser.
      
+
      Citations and references
      
+
      Each reference should be given a short name, e.g. “snark” 9. The syntax to cite that reference
+is “[#snark]_” in reStructuredText, or
+“[^snark]” in Markdown.
      
+
      The corresponding entry in the References
+section should look like this in reStructuredText:
      
+
      .. [#snark] `The Hunting of the Snark <https://www.gutenberg.org/files/29888/29888-h/29888-h.htm>_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
      
+
      or like this in Markdown::
      
+
      [^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
      
+
      Note that each entry must be on a single line regardless of how long
+that makes the line. In Markdown there must be a blank line between
+entries.
      
+
      The current rendering of a Markdown ZIP reorders the references
+according to their first use; the rendering of a reStructuredText ZIP
+keeps them in the same order as in the References section.
      
+
      To link to another section of the same ZIP, use
      
+
      `Section title`_
      
+
      in reStructuredText, or
      
+
      [Section title]
      
+
      in Markdown.
      
+
      Citing the Zcash
+protocol specification
      
+
      For references to the Zcash protocol specification, prefer to link to
+a section anchor, and name the reference as
+[^protocol-<anchor>]. This makes it more likely that
+the link will remain valid if sections are renumbered or if content is
+moved. The anchors in the protocol specification can be displayed by
+clicking on a section heading in most PDF viewers. References to
+particular sections should be versioned, even though the link will point
+to the most recent stable version.
      
+
      Do not include the “https://zips.z.cash/” part of URLs
+to ZIPs or the protocol spec.
      
+
      Reference implementation
      
+
      {This section is entirely optional; if present, it usually gives
+links to zcashd or zebrad PRs.}
      
+
      References
      
+
+
+
diff --git a/zip-guide-markdown.md b/zip-guide-markdown.md
new file mode 100644
index 00000000..4cc0091c
--- /dev/null
+++ b/zip-guide-markdown.md
@@ -0,0 +1,257 @@
+
+    ZIP: Unassigned {numbers are assigned by ZIP editors}
+    Title: {Something Short and To the Point}
+    Owners: First Owner 
+            ...
+    Credits: First Credited
+             ...
+    Status: Draft
+    Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational | Process}
+    Created: yyyy-mm-dd
+    License: {usually MIT}
+    Pull-Request: 
+
+
+# Don't Panic
+
+If this is your first time writing a ZIP, the structure and format may look
+intimidating. But really, it's just meant to reflect common-sense practice and
+some technical conventions. Feel free to start with a simple initial draft that
+gets ideas across, even if it doesn't quite follow this format. The community
+and ZIP editors will help you figure things out and get it into shape later.
+
+{Delete this section.}
+
+
+# Terminology
+
+{Edit this to reflect the key words that are actually used.}
+The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this
+document are to be interpreted as described in BCP 14 [^BCP14] when, and
+only when, they appear in all capitals.
+
+{Avoid duplicating definitions from other ZIPs. Instead use wording like this:}
+
+The terms "Mainnet" and "Testnet" in this document are to be interpreted as
+defined in the Zcash protocol specification [^protocol-networks].
+
+The term "full validator" in this document is to be interpreted as defined in
+the Zcash protocol specification [^protocol-blockchain].
+
+The terms below are to be interpreted as follows:
+
+{Term to be defined}
+
+: {Definition.}
+
+{Another term}
+
+: {Definition.}
+
+
+# Abstract
+
+{Describe what this proposal does, typically in a few paragraphs.
+
+The Abstract should only provide a summary of the ZIP; the ZIP should remain
+complete without the Abstract.
+
+Use links where applicable, e.g. [^protocol] [^protocol-introduction].}
+
+
+# Motivation
+
+{Why is this proposal needed?
+
+This is one of the most important sections of the ZIP, and should be detailed
+and comprehensive. It shouldn't include any of the actual specification --
+don't put conformance requirements in this section.
+
+Explain the status quo, why the status quo is in need of improvement,
+and if applicable, the history of how this area has changed. Then describe
+*at a high level* why this proposed solution addresses the perceived issues.
+It is ok if this is somewhat redundant with the abstract, but here you can
+go into a lot more detail.}
+
+
+# Requirements
+
+{Describe design constraints on, or goals for the solution -- typically one
+paragraph for each constraint or goal. Again, don't actually specify anything
+here; this section is primarily for use as a consistency check that what is
+specified meets the requirements.}
+
+
+# Non-requirements
+
+{This section is entirely optional. If it is present, it describes issues that
+the proposal is *not* attempting to address, that someone might otherwise think
+it does or should.}
+
+
+# Specification
+
+{Replace this entire section.}
+
+The Specification section describes what should change, using precise language and
+conformance key words. Anything that is *required in order to implement the ZIP*
+(or follow its process, in the case of a Process ZIP) should be in this section.
+
+Avoid overspecification! Also avoid underspecification. Specification is hard.
+Don't be afraid to ask for help.
+
+Feel free to copy from other ZIPs doing similar things, e.g. defining RPC calls,
+consensus rules, etc.
+
+ZIPs MUST take into account differences between the Zcash Mainnet and Testnet
+[^protocol-networks] where applicable. A consensus ZIP MUST be able to be deployed
+on both Mainnet and Testnet.
+
+Unless the specification is particularly simple, you will need to organise it under
+subheadings.
+
+## Example subheading
+
+At least while the ZIP is in Draft, we encourage writing open questions and TODOs.
+
+### Open questions
+
+* What happens if a full validator can't parse the fandangle as a doohicky?
+
+TODO: define byte encoding for the Jabberwock.
+
+## Comparison of ZIPs to RFCs
+
+Like RFCs, ZIPs are precise technical documents that SHOULD give enough
+implementation information to implement part of a Zcash-related protocol or follow a
+Zcash-related process [^zip-0000].
+
+ZIPs are different from RFCs in the following ways:
+
+* Many (but not all) ZIPs are "living documents"; they are updated in-place as
+  the relevant areas of the protocol or process change. Unlike in the RFC process,
+  making a change in an area described by a published ZIP does not *necessarily*
+  require creating a new ZIP, although that is an option if the change is extensive
+  enough to warrant it.
+* The expected structure of a ZIP is more constrained than an RFC. For example,
+  the Specification section is REQUIRED, and all of the conformance requirements
+  MUST go in that section. The ZIP editors will help you to ensure that things
+  go in the right sections.
+* Security considerations SHOULD be spread throughout the text, in the places
+  where they are most relevant.
+
+## Using mathematical notation
+
+Embedded LaTeX $x + y$ is allowed and encouraged in ZIPs. The syntax for inline
+math is "`:math:`latex code``" in reStructuredText or "`$latex code$`" in
+Markdown. The rendered HTML will use KaTeX [^katex], which only supports a subset
+of LaTeX, so you will need to double-check that the rendering is as intended.
+
+In general the conventions in the Zcash protocol specification SHOULD be followed.
+If you find this difficult, don't worry too much about it in initial drafts; the
+ZIP editors will catch any inconsistencies in review.
+
+## Notes and warnings
+
+:::info
+"`.. note::`" in reStructuredText, or "`:::info`" (terminated by
+"``:::``") in Markdown, can be used for an aside from the main text.
+
+The rendering of notes is colourful and may be distracting, so they should
+only be used for important points.
+:::
+
+:::warning
+"`.. warning::`" in reStructuredText, or "`:::warning`" (terminated by
+"`:::`") in Markdown, can be used for warnings.
+
+Warnings should be used very sparingly — for example to signal that a
+entire specification, or part of it, may be inapplicable or could cause
+significant interoperability or security problems. In most cases, a "MUST"
+or "SHOULD" conformance requirement is more appropriate.
+:::
+
+## Valid markup
+
+This is optional before publishing a PR, but to check whether a document is valid
+reStructuredText or Markdown, first install `rst2html5` and `pandoc`. E.g. on
+Debian-based distros::
+
+    sudo apt install python3-pip pandoc perl sed
+    pip3 install docutils==0.19 rst2html5
+
+Then, with `draft-myzip.rst` or `draft-myzip.md` in the root directory of a clone
+of this repo, run::
+
+    make draft-myzip.html
+
+(or just "`make`") and view `draft-myzip.html` in a web browser.
+
+## Citations and references
+
+Each reference should be given a short name, e.g. "snark" [^snark]. The syntax to cite
+that reference is "`[#snark]_`" in reStructuredText, or "`[^snark]`" in Markdown.
+
+The corresponding entry in the [References] section should look like this in
+reStructuredText:
+```rst
+.. [#snark] `The Hunting of the Snark _. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+```
+
+or like this in Markdown::
+```markdown
+[^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+```
+
+Note that each entry must be on a single line regardless of how long that makes the
+line. In Markdown there must be a blank line between entries.
+
+The current rendering of a Markdown ZIP reorders the references according to
+their first use; the rendering of a reStructuredText ZIP  keeps them in the same 
+order as in the References section.
+
+To link to another section of the same ZIP, use
+```rst
+`Section title`_
+```
+in reStructuredText, or
+```markdown
+[Section title]
+```
+in Markdown.
+
+### Citing the Zcash protocol specification
+
+For references to the Zcash protocol specification, prefer to link to a section
+anchor, and name the reference as `[^protocol-]`. This makes it more likely
+that the link will remain valid if sections are renumbered or if content is moved.
+The anchors in the protocol specification can be displayed by clicking on a section
+heading in most PDF viewers. References to particular sections should be versioned,
+even though the link will point to the most recent stable version.
+
+Do not include the "`https://zips.z.cash/`" part of URLs to ZIPs or the protocol spec.
+
+
+# Reference implementation
+
+{This section is entirely optional; if present, it usually gives links to zcashd or
+zebrad PRs.}
+
+
+# References
+
+[^BCP14]: [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14)
+
+[^protocol]: [Zcash Protocol Specification, Version 2022.3.8 or later](protocol/protocol.pdf)
+
+[^protocol-introduction]: [Zcash Protocol Specification, Version 2022.3.8. Section 1: Introduction](protocol/protocol.pdf#introduction)
+
+[^protocol-blockchain]: [Zcash Protocol Specification, Version 2022.3.8. Section 3.3: The Block Chain](protocol/protocol.pdf#blockchain)
+
+[^protocol-networks]: [Zcash Protocol Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks)
+
+[^katex]: [KaTeX - The fastest math typesetting library for the web](https://katex.org/)
+
+[^zip-0000]: [ZIP 0: ZIP Process](zip-0000.rst)
+
+[^snark]: [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
diff --git a/zip-guide.html b/zip-guide.html
index b2bcdcff..ccc02ec8 100644
--- a/zip-guide.html
+++ b/zip-guide.html
@@ -68,7 +68,7 @@ Pull-Request: <https://githu
                 
      
             
      
             
      Comparison of ZIPs to RFCs 
      
-                
      Like RFCs, ZIPs are precise technical documents that SHOULD give enough implementation information to implement part of a Zcash-related protocol or follow a Zcash-related process.
      
+                
      Like RFCs, ZIPs are precise technical documents that SHOULD give enough implementation information to implement part of a Zcash-related protocol or follow a Zcash-related process 7.
      
                 
      ZIPs are different from RFCs in the following ways:
      
                 
        
                     
      • Many (but not all) ZIPs are "living documents"; they are updated in-place as the relevant areas of the protocol or process change. Unlike in the RFC process, making a change in an area described by a published ZIP does not necessarily require creating a new ZIP, although that is an option if the change is extensive enough to warrant it.
        • 
@@ -79,7 +79,7 @@ Pull-Request: <https://githu
             
        Using mathematical notation 
        
                 
        Embedded
                     \(\LaTeX\)
-                 is allowed and encouraged in ZIPs. The syntax for inline math is ":math:`latex code`" in reStructuredText or "$latex code$" in Markdown. The rendered HTML will use KaTeX 6, which only supports a subset of
+                 is allowed and encouraged in ZIPs. The syntax for inline math is ":math:`latex code`" in reStructuredText or "$latex code$" in Markdown. The rendered HTML will use KaTeX 6, which only supports a subset of
                     \(\LaTeX\!\)
                 , so you will need to double-check that the rendering is as intended.
        
                 
        In general the conventions in the Zcash protocol specification SHOULD be followed. If you find this difficult, don't worry too much about it in initial drafts; the ZIP editors will catch any inconsistencies in review.
        
@@ -94,15 +94,25 @@ Pull-Request: <https://githu
                     
        Warnings should be used very sparingly — for example to signal that a entire specification, or part of it, may be inapplicable or could cause significant interoperability or security problems. In most cases, a "MUST" or "SHOULD" conformance requirement is more appropriate.
        
                 
             
        
-            
        Valid reStructuredText 
        
-                
        This is optional before publishing a PR, but to check whether a document is valid reStructuredText, first install rst2html5. E.g. on Debian-based distros:
        
+            
        Valid markup 
        
+                
        This is optional before publishing a PR, but to check whether a document is valid reStructuredText or Markdown, first install rst2html5 and pandoc. E.g. on Debian-based distros:
        
                 
        sudo apt install python3-pip pandoc perl sed
 pip3 install docutils==0.19 rst2html5
        
-                
        Then, with zip-xxxx.rst in the root directory of a clone of this repo, run:
        
-                
        make zip-xxxx.html
        
-                
        (or just make) and view zip-xxxx.html in a web browser.
        
+                
        Then, with draft-myzip.rst or draft-myzip.md in the root directory of a clone of this repo, run:
        
+                
        make draft-myzip.html
        
+                
        (or just "make") and view draft-myzip.html in a web browser.
        
             
        
-            
        Conventions for references 
        
+            
        Citations and references 
        
+                
        Each reference should be given a short name, e.g. "snark" 8. The syntax to cite that reference is "[#snark]_" in reStructuredText, or "[^snark]" in Markdown.
        
+                
        The corresponding entry in the References section should look like this in reStructuredText:
        
+                
        .. [#snark] `The Hunting of the Snark <https://www.gutenberg.org/files/29888/29888-h/29888-h.htm>`_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
        
+                
        or like this in Markdown:
        
+                
        [^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
        
+                
        Note that each entry must be on a single line regardless of how long that makes the line. In Markdown there must be a blank line between entries.
        
+                
        The current rendering of a Markdown ZIP reorders the references according to their first use; the rendering of a reStructuredText ZIP keeps them in the same order as in the References section.
        
+                
        To link to another section of the same ZIP, use "`Section title`_" in reStructuredText, or "[Section title]" in Markdown.
        
+            
        
+            
        Citing the Zcash protocol specification 
        
                 
        For references to the Zcash protocol specification, prefer to link to a section anchor, and name the reference as [#protocol-<anchor>]. This makes it more likely that the link will remain valid if sections are renumbered or if content is moved. The anchors in the protocol specification can be displayed by clicking on a section heading in most PDF viewers. References to particular sections should be versioned, even though the link will point to the most recent stable version.
        
                 
        Do not include the "https://zips.z.cash/" part of URLs to ZIPs or the protocol spec.
        
             
        
@@ -167,6 +177,14 @@ pip3 install docutils==0.19 rst2html5
    
                     
                 
             
+            
+                
+                    
+                        
+                        
+                    
+                
+            
    8The Hunting of the Snark. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
    
         
    
     
    
 
diff --git a/zip-guide.rst b/zip-guide.rst
index 950a78c5..04859404 100644
--- a/zip-guide.rst
+++ b/zip-guide.rst
@@ -132,7 +132,7 @@ Comparison of ZIPs to RFCs
 
 Like RFCs, ZIPs are precise technical documents that SHOULD give enough
 implementation information to implement part of a Zcash-related protocol or follow a
-Zcash-related process.
+Zcash-related process [#zip-0000]_.
 
 ZIPs are different from RFCs in the following ways:
 
@@ -180,23 +180,50 @@ Notes and warnings
     significant interoperability or security problems. In most cases, a "MUST"
     or "SHOULD" conformance requirement is more appropriate.
 
-Valid reStructuredText
-----------------------
+Valid markup
+------------
 
 This is optional before publishing a PR, but to check whether a document is valid
-reStructuredText, first install ``rst2html5``. E.g. on Debian-based distros::
+reStructuredText or Markdown, first install ``rst2html5`` and ``pandoc``. E.g. on
+Debian-based distros::
 
   sudo apt install python3-pip pandoc perl sed
   pip3 install docutils==0.19 rst2html5
 
-Then, with ``zip-xxxx.rst`` in the root directory of a clone of this repo, run::
+Then, with ``draft-myzip.rst`` or ``draft-myzip.md`` in the root directory of a
+clone of this repo, run::
 
-  make zip-xxxx.html
+  make draft-myzip.html
 
-(or just ``make``) and view ``zip-xxxx.html`` in a web browser.
+(or just "``make``") and view ``draft-myzip.html`` in a web browser.
 
-Conventions for references
---------------------------
+Citations and references
+------------------------
+
+Each reference should be given a short name, e.g. "snark" [#snark]_. The syntax to cite
+that reference is "``[#snark]_``" in reStructuredText, or "``[^snark]``" in Markdown.
+
+The corresponding entry in the `References`_ section should look like this in
+reStructuredText::
+
+  .. [#snark] `The Hunting of the Snark `_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+
+or like this in Markdown::
+
+  [^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+
+Note that each entry must be on a single line regardless of how long that makes the
+line. In Markdown there must be a blank line between entries.
+
+The current rendering of a Markdown ZIP reorders the references according to
+their first use; the rendering of a reStructuredText ZIP keeps them in the same
+order as in the References section.
+
+To link to another section of the same ZIP, use "```Section title`_``" in reStructuredText,
+or "``[Section title]``" in Markdown.
+
+Citing the Zcash protocol specification
+---------------------------------------
 
 For references to the Zcash protocol specification, prefer to link to a section
 anchor, and name the reference as ``[#protocol-]``. This makes it more likely
@@ -225,3 +252,4 @@ References
 .. [#protocol-networks] `Zcash Protocol Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet `_
 .. [#katex] `KaTeX - The fastest math typesetting library for the web `_
 .. [#zip-0000] `ZIP 0: ZIP Process `_
+.. [#snark] `The Hunting of the Snark `_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.