diff --git a/protocol/protocol.tex b/protocol/protocol.tex
index 43b1f1ab..ee1c2ffc 100644
--- a/protocol/protocol.tex
+++ b/protocol/protocol.tex
@@ -27,6 +27,7 @@
 \RequirePackage{subdepth}
 \RequirePackage{fix-cm}
 \RequirePackage{hyphenat}
+\RequirePackage{tocloft}
 
 \RequirePackage[style=alphabetic,maxbibnames=99,dateabbrev=false,urldate=iso8601,backref=true,backrefstyle=none,backend=biber]{biblatex}
 \addbibresource{zcash.bib}
@@ -72,6 +73,19 @@
 \setlength{\textheight}{9.2in}
 \setlength{\parindent}{0ex}
 \renewcommand{\arraystretch}{1.4}
+
+% <https://tex.stackexchange.com/a/49898/78411>
+\makeatletter
+\renewcommand{\@pnumwidth}{2em}
+\makeatother
+
+\newcommand{\pagenumfont}{\fontfamily{pnc}\selectfont\rule[-.2\baselineskip]{0pt}{1.4\baselineskip}}
+\renewcommand{\cftsecpagefont}{\pagenumfont}
+\renewcommand{\cftsubsecpagefont}{\pagenumfont}
+\renewcommand{\cftsubsubsecpagefont}{\pagenumfont}
+\renewcommand{\cftparapagefont}{\pagenumfont}
+
+\hfuzz=1pt
 %\overfullrule=2cm
 
 \setlength{\footnotemargin}{0.6em}
@@ -148,13 +162,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \setcounter{secnumdepth}{4}
 \setcounter{tocdepth}{4}
 
-\newcommand{\nstrut}[1]{\texorpdfstring{#1\rule[-.2\baselineskip]{0pt}{\baselineskip}}{#1}}
-\newcommand{\nsection}[1]{\section{\nstrut{#1}}}
-\newcommand{\nsubsection}[1]{\subsection{\nstrut{#1}}}
-\newcommand{\nsubsubsection}[1]{\subsubsection{\nstrut{#1}}}
-\newcommand{\nsubsubsubsection}[1]{\subsubsubsection{\nstrut{#1}}}
-\newcommand{\nsubsubsubsubsection}[1]{\subsubsubsubsection{\nstrut{#1}}}
-
 \newcommand{\introlist}{\needspace{15ex}}
 \newcommand{\introsection}{\needspace{35ex}}
 
@@ -1339,9 +1346,8 @@ and should not be used as a reference for the current protocol.}
 \noindent \textbf{Keywords:}~ \StrSubstitute[0]{\keywords}{,}{, }.
 \end{abstract}
 
-\vspace{-10ex}
 \phantomsection
-\addcontentsline{toc}{section}{\larger\nstrut{Contents}}
+\addcontentsline{toc}{section}{\larger{Contents}}
 
 \renewcommand{\contentsname}{}
 % <https://tex.stackexchange.com/a/182744/78411>
@@ -1351,7 +1357,7 @@ and should not be used as a reference for the current protocol.}
 \newpage
 
 
-\nsection{Introduction}
+\section{Introduction}
 
 \Zcash is an implementation of the \term{Decentralized Anonymous Payment}
 scheme \Zerocash \cite{BCG+2014}, with some security fixes and adjustments
@@ -1405,7 +1411,7 @@ as a Quadratic Arithmetic Program.
 \end{itemize}
 
 
-\nsubsection{Caution}
+\subsection{Caution}
 
 \Zcash security depends on consensus. Should a program interacting with the
 \Zcash network diverge from consensus, its security will be weakened or destroyed.
@@ -1420,7 +1426,7 @@ for security analysis, understanding of the protocol, and maintenance of
 \Zcash and related software. If you find any mistake in this specification,
 please contact \texttt{<security@z.cash>}.
 
-\nsubsection{High-level Overview}
+\subsection{High-level Overview}
 
 The following overview is intended to give a concise summary of the ideas
 behind the protocol, for an audience already familiar with \blockchain-based
@@ -1558,7 +1564,7 @@ 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.
 
 
-\nsection{Notation}
+\section{Notation}
 
 $\bit$ means the type of bit values, i.e.\ $\setof{0, 1}$.
 
@@ -1715,9 +1721,9 @@ $\PoWMaxAdjustUp$ will also be defined in that section.
 
 
 \introsection
-\nsection{Concepts}
+\section{Concepts}
 
-\nsubsection{Payment Addresses and Keys} \label{addressesandkeys}
+\subsection{Payment Addresses and Keys} \label{addressesandkeys}
 
 Users who wish to receive payments under this scheme first generate a
 random \spendingKey\sprout{ $\AuthPrivate$}.
@@ -1789,7 +1795,7 @@ exploit a hypothetical weakness in that cryptosystem.
 }
 
 \introsection
-\nsubsection{\Notes} \label{notes}
+\subsection{\Notes} \label{notes}
 
 \sprout{
 A \note (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value,
@@ -1906,7 +1912,7 @@ in zero knowledge while publically disclosing its \nullifier $\nf$,
 allowing $\nf$ to be used to prevent double-spending.
 
 
-\nsubsubsection{\NotePlaintexts{} and \Memos} \label{noteptconcept}
+\subsubsection{\NotePlaintexts{} and \Memos} \label{noteptconcept}
 
 Transmitted \notes are stored on the \blockchain in encrypted form, together with
 a \noteCommitment $\cm$.
@@ -1934,7 +1940,7 @@ The result of encryption forms part of a \notesCiphertext (see \crossref{inband}
 for further details).
 
 
-\nsubsection{The Block Chain} \label{blockchain}
+\subsection{The Block Chain} \label{blockchain}
 
 At a given point in time, each \fullValidator is aware of a set of candidate
 \blocks. These form a tree rooted at the \genesisBlock, where each node
@@ -1960,7 +1966,7 @@ the vast majority of nodes should eventually agree on their \bestValidBlockchain
 up to that height.
 
 
-\nsubsection{Transactions and Treestates} \label{transactions}
+\subsection{Transactions and Treestates} \label{transactions}
 
 Each \block contains one or more \transactions.
 
@@ -2016,7 +2022,7 @@ In a given \blockchain, \sapling{for each of \Sprout and \Sapling,}
 \sapling{There is no equivalent of interstitial \treestates for \Sapling.}
 
 
-\nsubsection{\JoinSplitTransfers{} and Descriptions} \label{joinsplit}
+\subsection{\JoinSplitTransfers{} and Descriptions} \label{joinsplit}
 
 A \joinSplitDescription is data included in a \transaction that describes a \joinSplitTransfer,
 i.e.\ a \shielded value transfer.
@@ -2064,7 +2070,7 @@ it is not known where it will eventually appear in a mined \block. Therefore the
 
 
 \sapling{
-\nsubsection{\SpendTransfers, \OutputTransfers, and their Descriptions} \label{spendsandoutputs}
+\subsection{\SpendTransfers, \OutputTransfers, and their Descriptions} \label{spendsandoutputs}
 
 \joinSplitTransfers are not used for \Sapling \notes. Instead, there is a
 separate \spendTransfer for each \shieldedInput, and a separate \outputTransfer
@@ -2118,7 +2124,7 @@ for the whole \transaction to balance.
 } %sapling
 
 
-\nsubsection{\NoteCommitmentTrees} \label{merkletree}
+\subsection{\NoteCommitmentTrees} \label{merkletree}
 
 \begin{center}
 \includegraphics[scale=.4]{incremental_merkle}
@@ -2144,7 +2150,7 @@ The \merkleHash associated with the \merkleNode at \merkleIndex $i$ in \merkleLa
 is denoted $\MerkleNode{h}{i}$.
 
 
-\nsubsection{\NullifierSets} \label{nullifierset}
+\subsection{\NullifierSets} \label{nullifierset}
 
 Each \fullValidator maintains a \nullifierSet logically associated with each \treestate.
 As valid \transactions containing \joinSplitTransfers \sapling{ or \spendTransfers} are
@@ -2165,7 +2171,7 @@ the same bit pattern.
 }}
 
 
-\nsubsection{Block Subsidy and Founders' Reward} \label{subsidyconcepts}
+\subsection{Block Subsidy and Founders' Reward} \label{subsidyconcepts}
 
 Like \Bitcoin, \Zcash creates currency when \blocks are mined. The value created on
 mining a \block is called the \blockSubsidy. It is composed of a \minerSubsidy and a
@@ -2177,7 +2183,7 @@ the \blockHeight, as defined in \crossref{blockchain}.
 These calculations are described in \crossref{subsidies}.
 
 
-\nsubsection{\CoinbaseTransactions}
+\subsection{\CoinbaseTransactions}
 
 The first \transaction in a block must be a \coinbaseTransaction, which should
 collect and spend any \minerSubsidy and \transactionFees paid by \transactions
@@ -2185,11 +2191,11 @@ included in this \block. The \coinbaseTransaction must also pay the \foundersRew
 as described in \crossref{foundersreward}.
 
 
-\nsection{Abstract Protocol}
+\section{Abstract Protocol}
 
-\nsubsection{Abstract Cryptographic Schemes}
+\subsection{Abstract Cryptographic Schemes}
 
-\nsubsubsection{\HashFunctions} \label{abstracthashes}
+\subsubsection{\HashFunctions} \label{abstracthashes}
 
 \sprout{
 $\MerkleCRH \typecolon \MerkleHashSprout \times \MerkleHashSprout \rightarrow \MerkleHashSprout$
@@ -2222,7 +2228,7 @@ It is instantiated in \crossref{equihashgen}.
 }
 
 \introsection
-\nsubsubsection{\PseudoRandomFunctions} \label{abstractprfs}
+\subsubsection{\PseudoRandomFunctions} \label{abstractprfs}
 
 $\PRF{x}{}$ is a \pseudoRandomFunction keyed by $x$.
 
@@ -2271,7 +2277,7 @@ $\PRFexpand{}$ is used in \crossref{saplingkeycomponents}; $\PRFnr{}$ is used in
 
 
 \introsection
-\nsubsubsection{\SymmetricEncryption} \label{abstractsym}
+\subsubsection{\SymmetricEncryption} \label{abstractsym}
 
 Let $\Sym$ be an \symmetricEncryptionScheme with keyspace $\Keyspace$, encrypting
 plaintexts in $\Plaintext$ to produce ciphertexts in $\Ciphertext$.
@@ -2293,7 +2299,7 @@ queries for a given key. The security notions INT-CTXT and IND-CPA are as define
 \cite{BN2007}.
 }
 
-\nsubsubsection{\KeyAgreement} \label{abstractkeyagreement}
+\subsubsection{\KeyAgreement} \label{abstractkeyagreement}
 
 A \keyAgreementScheme is a cryptographic protocol in which two parties agree
 a shared secret, each using their private key and the other party's public key.
@@ -2329,7 +2335,7 @@ More precise formalization of these requirements is beyond the scope of this
 specification.
 
 
-\nsubsubsection{\KeyDerivation} \label{abstractkdf}
+\subsubsection{\KeyDerivation} \label{abstractkdf}
 
 A \keyDerivationFunction is defined for a particular \keyAgreementScheme and
 \symmetricEncryptionScheme; it takes the shared secret produced by the key
@@ -2387,7 +2393,7 @@ This is not considered to be a significant security weakness.
 
 
 \introlist
-\nsubsubsection{Signature} \label{abstractsig}
+\subsubsection{Signature} \label{abstractsig}
 
 A signature scheme $\Sig$ defines:
 
@@ -2451,7 +2457,7 @@ confusion that it might.}
 
 
 \introlist
-\nsubsubsubsection{Signature with Re-Randomizable Keys} \label{abstractsigrerand}
+\subsubsubsection{Signature with Re-Randomizable Keys} \label{abstractsigrerand}
 
 A signature scheme with re-randomizable keys $\Sig$ is a signature scheme that
 additionally defines:
@@ -2532,7 +2538,7 @@ $(m^*, \sigma^*) \not\in \Oracle_{\sk}\mathsf{.}Q$.
 
 
 \introlist
-\nsubsubsection{Commitment} \label{abstractcommit}
+\subsubsection{Commitment} \label{abstractcommit}
 
 A \commitmentScheme is a function that, given a random \commitmentTrapdoor
 and an input, can be used to commit to the input in such a way that:
@@ -2571,7 +2577,7 @@ the computational binding security requirement.
 
 
 \introsection
-\nsubsubsection{\RepresentedGroup} \label{abstractgroup}
+\subsubsection{\RepresentedGroup} \label{abstractgroup}
 
 A \representedGroup $\GroupG{}$ consists of:
 
@@ -2606,7 +2612,7 @@ we write $\scalarmult{k}{G}$ for $\vsum{i = 1}{k} G$.
 
 \sapling{
 \introsection
-\nsubsubsection{\HashExtractor} \label{abstractextractor}
+\subsubsection{\HashExtractor} \label{abstractextractor}
 
 A \hashExtractor for a \representedGroup $\GroupG{}$ is a function
 $\ExtractG \typecolon \GroupG{} \rightarrow T$ for some type $T$,
@@ -2622,7 +2628,7 @@ efficiently computable left inverse.
 
 \sapling{
 \introlist
-\nsubsubsection{\GroupHash} \label{abstractgrouphash}
+\subsubsection{\GroupHash} \label{abstractgrouphash}
 
 Given a represented group $\GroupG{}$ and a type $\CRSType$, we define a
 \term{family of group hashes into\, $\GroupG{}$} as a function
@@ -2661,7 +2667,7 @@ such that $\vsum{i = 1}{n}\left(\scalarmult{x_i}{\GroupGHash{\CRS}(m_i)}\right)
 
 
 \introlist
-\nsubsubsection{\RepresentedPairing} \label{abstractpairing}
+\subsubsection{\RepresentedPairing} \label{abstractpairing}
 
 A \representedPairing $\GroupP{}$ consists of:
 
@@ -2685,7 +2691,7 @@ A \representedPairing $\GroupP{}$ consists of:
         \end{itemize}
 \end{itemize}
 
-\nsubsubsection{\ZeroKnowledgeProvingSystem} \label{abstractzk}
+\subsubsection{\ZeroKnowledgeProvingSystem} \label{abstractzk}
 
 A \zeroKnowledgeProvingSystem is a cryptographic protocol that allows
 proving a particular \statement, dependent on \primary and \auxiliaryInputs,
@@ -2798,9 +2804,9 @@ them to be the $\Groth$ \provingKeys and
 } %sapling
 
 
-\nsubsection{\KeyComponents} \label{keycomponents}
+\subsection{\KeyComponents} \label{keycomponents}
 
-\notsprout{\nsubsubsection{\Sprout{} \KeyComponents}} \label{sproutkeycomponents}
+\notsprout{\subsubsection{\Sprout{} \KeyComponents}} \label{sproutkeycomponents}
 
 Let $\PRFaddr{}$ be a \pseudoRandomFunction, instantiated in \crossref{concreteprfs}.
 
@@ -2822,7 +2828,7 @@ as follows:}
 \end{tabular}
 
 \sapling{
-\nsubsubsection{\Sapling{} \KeyComponents} \label{saplingkeycomponents}
+\subsubsection{\Sapling{} \KeyComponents} \label{saplingkeycomponents}
 
 Let $\PRFexpand{}$ be a \pseudoRandomFunction, instantiated in \crossref{concreteprfs}.
 
@@ -2910,7 +2916,7 @@ The resulting \diversifiedPaymentAddress is $(\Diversifier, \DiversifiedTransmit
 } %sapling
 
 
-\nsubsection{\JoinSplitDescriptions} \label{joinsplitdesc}
+\subsection{\JoinSplitDescriptions} \label{joinsplitdesc}
 
 A \joinSplitTransfer, as specified in \crossref{joinsplit}, is encoded in
 \transactions as a \joinSplitDescription.
@@ -2977,7 +2983,7 @@ $\hSigCRH$ is instantiated in \crossref{hsigcrh}.
 
 
 \sapling{
-\nsubsection{\SpendDescriptions} \label{spenddesc}
+\subsection{\SpendDescriptions} \label{spenddesc}
 
 A \spendTransfer, as specified in \crossref{spendsandoutputs}, is encoded in
 \transactions as a \spendDescription.
@@ -3014,7 +3020,7 @@ where
 
 
 \sapling{
-\nsubsection{\OutputDescriptions} \label{outputdesc}
+\subsection{\OutputDescriptions} \label{outputdesc}
 
 An \outputTransfer, as specified in \crossref{spendsandoutputs}, is encoded in
 \transactions as an \outputDescription.
@@ -3048,9 +3054,9 @@ where
 
 
 \introlist
-\nsubsection{Sending \Notes} \label{send}
+\subsection{Sending \Notes} \label{send}
 
-\notsprout{\nsubsubsection{Sending \Notes{} (\Sprout)}} \label{sproutsend}
+\notsprout{\subsubsection{Sending \Notes{} (\Sprout)}} \label{sproutsend}
 
 In order to send \shielded value, the sender constructs a \transaction
 containing one or more \joinSplitDescriptions. This involves first generating
@@ -3095,7 +3101,7 @@ the private \joinSplitSigningKey:
 Then the encoded \transaction including $\joinSplitSig$ is submitted to the network.
 
 
-\nsubsubsection{\DummyNotes\notsprout{ (\Sprout)}} \label{dummynotes}
+\subsubsection{\DummyNotes\notsprout{ (\Sprout)}} \label{dummynotes}
 
 The fields in a \joinSplitDescription allow for $\NOld$ input \notes, and
 $\NNew$ output \notes. In practice, we may wish to encode a \joinSplitTransfer
@@ -3123,7 +3129,7 @@ A \dummy output \note is constructed as normal but with zero value, and
 sent to a random \paymentAddress.
 
 \sapling{
-\nsubsubsection{Sending \Notes{} (\Sapling)} \label{saplingsend}
+\subsubsection{Sending \Notes{} (\Sapling)} \label{saplingsend}
 
 In order to send \shielded value, the sender constructs a \transaction
 containing one or more \shieldedOutputs.
@@ -3197,7 +3203,7 @@ The encoded \transaction is submitted to the network.
 } %sapling
 
 
-\nsubsection{Merkle path validity} \label{merklepath}
+\subsection{Merkle path validity} \label{merklepath}
 
 \sprout{
 The depth of the \noteCommitmentTree is $\MerkleDepth$ (defined in \crossref{constants}).
@@ -3259,7 +3265,7 @@ where
 Given such a \merklePath, it is possible to verify that \merkleLeafNode
 $\MerkleNode{\MerkleDepth}{i}$ is in a tree with a given \merkleRoot $\rt = \MerkleNode{0}{0}$.
 
-\nsubsection{Non-malleability} \label{nonmalleability}
+\subsection{Non-malleability} \label{nonmalleability}
 
 \Bitcoin defines several \sighashTypes that cover various parts of a transaction.
 \changed{In \Zcash, all of these \sighashTypes are extended to cover the \Zcash-specific
@@ -3309,7 +3315,7 @@ to $\joinSplitPubKey$ to sign this \transaction.
 }
 
 
-\nsubsection{Balance} \label{balance} \label{saplingbalance}
+\subsection{Balance} \label{balance} \label{saplingbalance}
 
 A \joinSplitTransfer can be seen, from the perspective of the \transaction, as
 an input \changed{and an output simultaneously}.
@@ -3336,7 +3342,7 @@ according to client implementation.
 \sapling{\todo{Add details of balance checking for \Sapling \transactions.}}
 
 
-\nsubsection{\NoteCommitments{} and \Nullifiers} \label{commitmentsandnullifiers}
+\subsection{\NoteCommitments{} and \Nullifiers} \label{commitmentsandnullifiers}
 
 A \transaction that contains one or more
 \joinSplitDescriptions\sapling{ or \spendDescriptions}, when entered
@@ -3372,9 +3378,9 @@ $\scalarmult{\PRFnr{\AuthProvePublic}(\NoteAddressRand)}{\AuthSignPublic}$.
 
 \introsection
 
-\nsubsection{\ZkSNARKStatements} \label{snarkstatements}
+\subsection{\ZkSNARKStatements} \label{snarkstatements}
 
-\nsubsubsection{\JoinSplitStatement{} \notsprout{(\Sprout)}} \label{joinsplitstatement}
+\subsubsection{\JoinSplitStatement{} \notsprout{(\Sprout)}} \label{joinsplitstatement}
 
 A valid instance of $\ProofJoinSplit$ assures that given a \term{primary input}:
 
@@ -3465,7 +3471,7 @@ For details of the form and encoding of proofs, see \crossref{phgr}.
 
 \sapling{
 \introsection
-\nsubsubsection{\SpendStatement{} (\Sapling)} \label{spendstatement}
+\subsubsection{\SpendStatement{} (\Sapling)} \label{spendstatement}
 
 A valid instance of $\ProofSpend$ assures that given a \term{primary input}:
 
@@ -3540,7 +3546,7 @@ For details of the form and encoding of \spendStatement proofs, see \crossref{gr
 
 \sapling{
 \introsection
-\nsubsubsection{\OutputStatement{} (\Sapling)} \label{outputstatement}
+\subsubsection{\OutputStatement{} (\Sapling)} \label{outputstatement}
 
 \todo{}
 
@@ -3548,7 +3554,7 @@ For details of the form and encoding of \outputStatement proofs, see \crossref{g
 } %sapling
 
 
-\nsubsection{In-band secret distribution} \label{inband}
+\subsection{In-band secret distribution} \label{inband}
 
 The secrets that need to be transmitted to a recipient of funds in order for
 them to later spend, are $\Value$, $\NoteAddressRand$, $\NoteCommitRand$\sapling{,
@@ -3587,7 +3593,7 @@ For both encryption and decryption,
 \end{itemize}
 }
 
-\nsubsubsection{Encryption}
+\subsubsection{Encryption}
 
 Let $\TransmitPublicNew{\allNew}$ be the \transmissionKeys
 for the intended recipient addresses of each new \note.
@@ -3627,7 +3633,7 @@ further security considerations, for example of how to validate a \note received
 out-of-band, which are not addressed in this document.
 }
 
-\nsubsubsection{Decryption by a Recipient}
+\subsubsection{Decryption by a Recipient}
 
 Let $\InViewingKey = (\AuthPublic, \TransmitPrivate)$ be the recipient's \incomingViewingKey,
 and let $\TransmitPublic$ be the corresponding \transmissionKey derived from
@@ -3681,14 +3687,14 @@ See \crossref{inbandrationale} for further discussion of the security and
 engineering rationale behind this encryption scheme.
 
 
-\nsection{Concrete Protocol}
+\section{Concrete Protocol}
 
-\nsubsection{Caution}
+\subsection{Caution}
 
 \todo{Explain the kind of things that can go wrong with linkage between
 abstract and concrete protocol. E.g. \crossref{internalh}}
 
-\nsubsection{Integers, Bit Sequences, and Endianness} \label{boxnotation} \label{endian}
+\subsection{Integers, Bit Sequences, and Endianness} \label{boxnotation} \label{endian}
 
 All integers in \emph{\Zcash-specific} encodings are unsigned, have a fixed
 bit length, and are encoded in little-endian byte order \emph{unless otherwise
@@ -3729,7 +3735,7 @@ is toward the left of a diagram. Where bit fields are used, the text will
 clarify their position in each case.
 
 \introlist
-\nsubsection{Constants} \label{constants}
+\subsection{Constants} \label{constants}
 
 Define:
 
@@ -3778,11 +3784,11 @@ Define:
 
 
 \introlist
-\nsubsection{Concrete Cryptographic Schemes}
+\subsection{Concrete Cryptographic Schemes}
 
-\nsubsubsection{\HashFunctions}
+\subsubsection{\HashFunctions}
 
-\nsubsubsubsection{SHA-256 and SHA256Compress \HashFunctions} \label{concretesha256}
+\subsubsubsection{SHA-256 and SHA256Compress \HashFunctions} \label{concretesha256}
 
 SHA-256 is defined by \cite{NIST2015}.
 
@@ -3809,7 +3815,7 @@ $\MerkleCRHSprout$.
 \todo{Specify bit order.}
 
 
-\nsubsubsubsection{\BlakeTwo{} \HashFunction} \label{concreteblake2}
+\subsubsubsection{\BlakeTwo{} \HashFunction} \label{concreteblake2}
 
 BLAKE2 is defined by \cite{ANWW2013}.
 \sprout{\Zcash uses only the $\BlakeTwobGeneric$ variant.}
@@ -3854,7 +3860,7 @@ $\CRHivk$, and $\GroupJHash{}$.
 
 
 \introsection
-\nsubsubsubsection{\MerkleTree{} \HashFunction} \label{merklecrh}
+\subsubsubsection{\MerkleTree{} \HashFunction} \label{merklecrh}
 
 \newsavebox{\merklebox}
 \begin{lrbox}{\merklebox}
@@ -3938,7 +3944,7 @@ as noted in \crossref{concretewindowedcommit}.
 
 
 \introlist
-\nsubsubsubsection{\hSigText{} \HashFunction} \label{hsigcrh}
+\subsubsubsection{\hSigText{} \HashFunction} \label{hsigcrh}
 
 \newsavebox{\hsigbox}
 \begin{lrbox}{\hsigbox}
@@ -3982,7 +3988,7 @@ $\BlakeTwobOf{256}{\ascii{ZcashComputehSig}, x}$ must be collision-resistant on
 
 \sapling{
 \introlist
-\nsubsubsubsection{\CRHivkText{} \HashFunction} \label{concretecrhivk}
+\subsubsubsection{\CRHivkText{} \HashFunction} \label{concretecrhivk}
 
 $\CRHivk$ is used to derive the \incomingViewingKey $\InViewingKey$
 for a \Sapling \paymentAddress.
@@ -4028,7 +4034,7 @@ the same effect as using that feature.
 
 \sapling{
 \introlist
-\nsubsubsubsection{\PedersenHashFunction} \label{concretepedersenhash}
+\subsubsubsection{\PedersenHashFunction} \label{concretepedersenhash}
 
 $\PedersenHash$ is an algebraic hash function with collision resistance
 (for fixed input length) derived from assumed hardness of the
@@ -4177,7 +4183,7 @@ The right-hand-side is a nonsquare in $\GF{\ParamJ{r}}$, so there are no solutio
 
 
 \sapling{
-\nsubsubsubsection{Mixing Pedersen \HashFunction} \label{concretemixinghash}
+\subsubsubsection{Mixing Pedersen \HashFunction} \label{concretemixinghash}
 
 A mixing \xPedersenHash is used to compute $\NoteAddressRand$ from
 $\cm$ and $\NotePosition$ in \crossref{commitmentsandnullifiers}. It takes as
@@ -4204,7 +4210,7 @@ See \crossref{cctmixinghash} for efficient circuit implementation of this functi
 
 
 \introlist
-\nsubsubsubsection{Equihash Generator} \label{equihashgen}
+\subsubsubsection{Equihash Generator} \label{equihashgen}
 
 $\EquihashGen{n, k}$ is a specialized \hashFunction that maps an input
 and an index to an output of length $n$ bits. It is used in \crossref{equihash}.
@@ -4259,7 +4265,7 @@ $n = 200$).
 
 
 \introsection
-\nsubsubsection{\PseudoRandomFunctions} \label{concreteprfs}
+\subsubsection{\PseudoRandomFunctions} \label{concreteprfs}
 
 $\PRFaddr{}$, $\PRFnf{}$, $\PRFpk{}$\changed{, and $\PRFrho{}$},
 described in \crossref{abstractprfs}, are all instantiated using the \shaCompressFunction
@@ -4453,7 +4459,7 @@ It is instantiated using the $\BlakeTwosGeneric$ \hashFunction defined in \cross
 
 
 \introsection
-\nsubsubsection{\SymmetricEncryption} \label{concretesym}
+\subsubsection{\SymmetricEncryption} \label{concretesym}
 
 \changed{
 Let $\Keyspace := \bitseq{256}$, $\Plaintext := \byteseqs$, and $\Ciphertext := \byteseqs$.
@@ -4476,9 +4482,9 @@ used; this has a 32-bit block count and a 96-bit nonce, rather than a 64-bit
 block count and 64-bit nonce as in the original definition of $\SymCipher$.
 }
 
-\nsubsubsection{\KeyAgreementAndDerivation} \label{concretekaandkdf}
+\subsubsection{\KeyAgreementAndDerivation} \label{concretekaandkdf}
 
-\nsubsubsubsection{\SproutOrNothing \KeyAgreement} \label{concretesproutkeyagreement}
+\subsubsubsection{\SproutOrNothing \KeyAgreement} \label{concretesproutkeyagreement}
 
 \changed{
 The \keyAgreementScheme specified in \crossref{abstractkeyagreement} is
@@ -4509,7 +4515,7 @@ Define $\KASproutAgree(n, q) := \CurveMultiply(n, q)$.
 }
 
 \introsection
-\nsubsubsubsection{\SproutOrNothing \KeyDerivation} \label{concretesproutkdf}
+\subsubsubsection{\SproutOrNothing \KeyDerivation} \label{concretesproutkdf}
 
 \newsavebox{\kdftagbox}
 \begin{lrbox}{\kdftagbox}
@@ -4552,7 +4558,7 @@ $\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}.
 
 
 \sapling{
-\nsubsubsubsection{\Sapling \KeyAgreement} \label{concretesaplingkeyagreement}
+\subsubsubsection{\Sapling \KeyAgreement} \label{concretesaplingkeyagreement}
 
 The \keyAgreementScheme specified in \crossref{abstractkeyagreement} is
 instantiated using Diffie-Hellman with cofactor multiplication on $\JubjubCurve$
@@ -4575,7 +4581,7 @@ the type of $\JubjubCurve$ secret keys. \todo{expand this}
 \end{lrbox}
 
 \sapling{
-\nsubsubsubsection{\Sapling \KeyDerivation} \label{concretesaplingkdf}
+\subsubsubsection{\Sapling \KeyDerivation} \label{concretesaplingkdf}
 
 The $\KDFSapling$ \keyDerivationFunction specified in \crossref{abstractkdf}
 is instantiated using $\BlakeTwob{256}$ as follows:
@@ -4594,7 +4600,7 @@ $\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}.
 } %sapling
 
 
-\nsubsubsection{\JoinSplitSignature} \label{concretejssig}
+\subsubsection{\JoinSplitSignature} \label{concretejssig}
 
 $\JoinSplitSig$ is specified in \crossref{abstractsig}.
 
@@ -4643,7 +4649,7 @@ The encoding of a public key is as defined in \cite{BDLSY2012}.
 }
 
 \sapling{
-\nsubsubsection{\SpendAuthSignature} \label{concretespendauthsig}
+\subsubsection{\SpendAuthSignature} \label{concretespendauthsig}
 
 $\SpendAuthSig$ is a signature scheme with re-randomizable keys specified in
 \crossref{abstractsigrerand}.
@@ -4655,9 +4661,9 @@ It is instantiated as EdJubjub, which is defined as $\EdDSA$ \cite{BJLSY2015} ov
 } %sapling
 
 \introlist
-\nsubsubsection{Commitment schemes} \label{concretecommit}
+\subsubsection{Commitment schemes} \label{concretecommit}
 
-\nsubsubsubsection{\SproutOrNothing{} \NoteCommitments} \label{concretesproutcommit}
+\subsubsubsection{\SproutOrNothing{} \NoteCommitments} \label{concretesproutcommit}
 
 \newsavebox{\cmbox}
 \begin{lrbox}{\cmbox}
@@ -4699,7 +4705,7 @@ The leading byte of the $\SHAFull$ input is $\hexint{B0}$.
 
 
 \sapling{
-\nsubsubsubsection{Windowed Pedersen commitments} \label{concretewindowedcommit}
+\subsubsubsection{Windowed Pedersen commitments} \label{concretewindowedcommit}
 
 We construct \quotedterm{windowed} \xPedersenCommitments by reusing the \xPedersenHash
 construction from \crossref{concretepedersenhash}, and adding a randomized point
@@ -4742,7 +4748,7 @@ $\MerkleDepthSapling < 64$.
 
 
 \sapling{
-\nsubsubsubsection{Homomorphic Pedersen commitments} \label{concretehomomorphiccommit}
+\subsubsubsection{Homomorphic Pedersen commitments} \label{concretehomomorphiccommit}
 
 The windowed Pedersen commitments defined in the preceding section are
 highly efficient, but they do not support the homomorphic property we
@@ -4781,9 +4787,9 @@ instantiated using $\HomomorphicPedersenCommit{}$ as follows:
 
 
 \introsection
-\nsubsubsection{\RepresentedGroupsAndPairings} \label{concretepairing}
+\subsubsection{\RepresentedGroupsAndPairings} \label{concretepairing}
 
-\nsubsubsubsection{\BNRepresentedPairing} \label{bnpairing}
+\subsubsubsection{\BNRepresentedPairing} \label{bnpairing}
 
 The \representedPairing $\BNCurve$ is defined in this section.
 
@@ -4943,7 +4949,7 @@ the square root exists, or that the encoding represents a point on the curve.
 \end{lrbox}
 
 \sapling{
-\nsubsubsubsection{\BLSRepresentedPairing} \label{blspairing}
+\subsubsubsection{\BLSRepresentedPairing} \label{blspairing}
 
 The \representedPairing $\BLSCurve$ is defined in this section. Parameters are taken from
 \cite{Bowe2017}.
@@ -5049,7 +5055,7 @@ curve.
 }
 
 \sapling{
-\nsubsubsubsection{\Jubjub} \label{jubjub}
+\subsubsubsection{\Jubjub} \label{jubjub}
 
 The \representedGroup $\JubjubCurve$ is defined in this section.
 
@@ -5112,7 +5118,7 @@ large prime-order subgroup.
 
 
 \sapling{
-\nsubsubsubsection{\HashExtractor{} for \Jubjub} \label{concreteextractorjubjub}
+\subsubsubsection{\HashExtractor{} for \Jubjub} \label{concreteextractorjubjub}
 
 Let $\SelectuOf{(u, \varv)} = u$ and let $\SelectvOf{(u, \varv)} = \varv$.
 
@@ -5163,7 +5169,7 @@ is injective on points in $G$.
 
 \sapling{
 \introsection
-\nsubsubsubsection{\GroupHash{} into \Jubjub} \label{concretegrouphashjubjub}
+\subsubsubsection{\GroupHash{} into \Jubjub} \label{concretegrouphashjubjub}
 
 %Let $\CRS$ be the $64$-byte \commonRandomString given by the $\SHAd$ hash
 %(expressed as an ASCII lowercase hex string in RPC byte order \cite{Bitc-ByteOrder})
@@ -5205,9 +5211,9 @@ Let $\FindGroupJHashOf{D, M} =
 }
 
 
-\nsubsubsection{\ZeroKnowledgeProvingSystems}
+\subsubsection{\ZeroKnowledgeProvingSystems}
 
-\nsubsubsubsection{\PHGRProvingSystem} \label{phgr}
+\subsubsubsection{\PHGRProvingSystem} \label{phgr}
 
 \Zcash uses \zkSNARKs generated by its fork of \libsnark \cite{libsnark-fork}
 with the \provingSystem described in \cite{BCTV2015}, which is a refinement of
@@ -5287,7 +5293,7 @@ verifier \MUST check, for the encoding of each element, that:
 \end{lrbox}
 
 \sapling{
-\nsubsubsubsection{\GrothProvingSystem} \label{groth}
+\subsubsubsection{\GrothProvingSystem} \label{groth}
 
 \Sapling uses \zkSNARKs generated by the \bellman library, with the \provingSystem
 described in \cite{Grot2016}.
@@ -5337,7 +5343,7 @@ verifier \MUST check, for the encoding of each element, that:
 \end{itemize}
 }
 
-\nsubsection{\NotePlaintexts{} and \Memos} \label{notept}
+\subsection{\NotePlaintexts{} and \Memos} \label{notept}
 
 As explained in \crossref{noteptconcept}, transmitted \notes are stored on
 the \blockchain in encrypted form.
@@ -5440,7 +5446,7 @@ to the raw encoding of a \Sapling \paymentAddress in \crossref{saplingpaymentadd
 }
 
 
-\nsubsection{Encodings of Addresses and Keys} \label{addressandkeyencoding}
+\subsection{Encodings of Addresses and Keys} \label{addressandkeyencoding}
 
 This section describes how \Zcash encodes \paymentAddresses\changed{, \incomingViewingKeys,}
 and \spendingKeys.
@@ -5461,7 +5467,7 @@ The language consisting of the following encoding possibilities is prefix-free.
 
 
 \introsection
-\nsubsubsection{\TransparentAddresses} \label{transparentaddrencoding}
+\subsubsection{\TransparentAddresses} \label{transparentaddrencoding}
 
 \xTransparentAddresses are either P2SH (Pay to Script Hash) \cite{BIP-13}
 or P2PKH (Pay to Public Key Hash) \cite{Bitc-P2PKH} addresses.
@@ -5521,13 +5527,13 @@ The raw encoding of a P2PKH address consists of:
 \end{pnotes}
 
 
-\nsubsubsection{\Transparent{} Private Keys} \label{transparentkeyencoding}
+\subsubsection{\Transparent{} Private Keys} \label{transparentkeyencoding}
 
 These are encoded in the same way as in \Bitcoin \cite{Bitc-Base58},
 for both the production and test networks.
 
 
-\nsubsubsection{\SproutOrNothing \PaymentAddresses} \label{sproutpaymentaddrencoding}
+\subsubsection{\SproutOrNothing \PaymentAddresses} \label{sproutpaymentaddrencoding}
 
 A \SproutOrNothing \paymentAddress consists of $\AuthPublic \typecolon \PRFOutput$
 and $\TransmitPublic \typecolon \KASproutPublic$.
@@ -5572,7 +5578,7 @@ cause the first two characters of the Base58Check encoding to be fixed as
 
 
 \sapling{
-\nsubsubsection{\Sapling \PaymentAddresses} \label{saplingpaymentaddrencoding}
+\subsubsection{\Sapling \PaymentAddresses} \label{saplingpaymentaddrencoding}
 
 A \Sapling \paymentAddress consists of $\Diversifier \typecolon \DiversifierType$
 and $\DiversifiedTransmitPublic \typecolon \KASaplingPublic$.
@@ -5604,7 +5610,7 @@ For addresses on the test network, the \humanReadablePart is \ascii{ztestsapling
 }
 
 
-\nsubsubsection{\SproutOrNothing \IncomingViewingKeys} \label{sproutinviewingkeyencoding}
+\subsubsection{\SproutOrNothing \IncomingViewingKeys} \label{sproutinviewingkeyencoding}
 
 \changed{
 An \incomingViewingKey consists of $\AuthPublic \typecolon \PRFOutput$ and
@@ -5658,7 +5664,7 @@ cause the first four characters of the Base58Check encoding to be fixed as
 
 
 \sapling{
-\nsubsubsection{\Sapling \IncomingViewingKeys} \label{saplinginviewingkeyencoding}
+\subsubsection{\Sapling \IncomingViewingKeys} \label{saplinginviewingkeyencoding}
 
 A \Sapling \incomingViewingKey consists of $\InViewingKey \typecolon \KASproutPrivate$
 (see \crossref{concretesaplingkeyagreement}).
@@ -5689,7 +5695,7 @@ For \incomingViewingKeys on the test network, the \humanReadablePart is \ascii{z
 
 
 \sapling{
-\nsubsubsection{\Sapling \FullViewingKeys} \label{saplingfullviewingkeyencoding}
+\subsubsection{\Sapling \FullViewingKeys} \label{saplingfullviewingkeyencoding}
 
 A \Sapling \fullViewingKey consists of $\AuthSignPublic \typecolon \GroupJ$
 and $\AuthProvePublic \typecolon \GroupJ$.
@@ -5721,7 +5727,7 @@ For \incomingViewingKeys on the test network, the \humanReadablePart is \ascii{z
 }
 
 
-\nsubsubsection{\SproutOrNothing \SpendingKeys} \label{sproutspendingkeyencoding}
+\subsubsection{\SproutOrNothing \SpendingKeys} \label{sproutspendingkeyencoding}
 
 A \SproutOrNothing \spendingKey consists of $\AuthPrivate$, which is a sequence of
 \changed{$252$} bits (see \crossref{sproutkeycomponents}).
@@ -5770,7 +5776,7 @@ The zero padding occupies the most significant 4 bits of the third byte.
 
 
 \sapling{
-\nsubsubsection{\Sapling \SpendingKeys} \label{saplingspendingkeyencoding}
+\subsubsection{\Sapling \SpendingKeys} \label{saplingspendingkeyencoding}
 
 A \Sapling \spendingKey consists of $\SpendingKey \typecolon \bitseq{\SpendingKeyLength}$
 (see \crossref{sproutkeycomponents}).
@@ -5794,7 +5800,7 @@ For \spendingKeys on the test network, the \humanReadablePart is \ascii{secret-s
 
 
 \introlist
-\nsubsection{\SproutZKParameters} \label{sproutparameters}
+\subsection{\SproutZKParameters} \label{sproutparameters}
 
 For the \Zcash production \blockchain and testnet, the $\SHAFull$ hashes of the
 \provingKey and \verifyingKey for the \SproutOrZcash \joinSplitStatement, encoded in
@@ -5810,7 +5816,7 @@ These parameters were obtained by a multi-party computation described in
 
 \sapling{
 \introsection
-\nsubsection{\SaplingZKParameters} \label{saplingparameters}
+\subsection{\SaplingZKParameters} \label{saplingparameters}
 
 The $\SHAFull$ hashes of the \provingKey and \verifyingKey for the \Sapling
 \spendStatement, encoded in \bellman format, are:
@@ -5833,7 +5839,7 @@ These parameters were obtained by a multi-party computation described in \todo{}
 
 \sapling{
 \introsection
-\nsection{\Sapling Transition} \label{saplingtransition}
+\section{\Sapling Transition} \label{saplingtransition}
 
 \todo{Separate this out into a ZIP that describes the bilateral
 hard fork strategy generally, and then describe the \Sapling
@@ -5899,9 +5905,9 @@ for use by \Sapling \transactions.
 
 
 \introsection
-\nsection{Consensus Changes from \Bitcoin}
+\section{Consensus Changes from \Bitcoin}
 
-\nsubsection{Encoding of \Transactions} \label{txnencoding}
+\subsection{Encoding of \Transactions} \label{txnencoding}
 
 \nuzero{\pnote{This section has not yet been updated for v3 transactions; see ZIP 202.}}
 
@@ -6028,7 +6034,7 @@ Software that creates \transactions{} \SHOULD use version $1$ for \transactions
 }
 
 \introsection
-\nsubsection{Encoding of \JoinSplitDescriptions} \label{joinsplitencoding}
+\subsection{Encoding of \JoinSplitDescriptions} \label{joinsplitencoding}
 
 An abstract \joinSplitDescription, as described in \crossref{joinsplit}, is encoded in
 a \transaction as an instance of a \type{JoinSplitDescription} type as follows:
@@ -6086,7 +6092,7 @@ Consensus rules applying to a \joinSplitDescription are given in \crossref{joins
 
 \sapling{
 \introsection
-\nsubsection{Encoding of \SpendDescriptions} \label{spendencoding}
+\subsection{Encoding of \SpendDescriptions} \label{spendencoding}
 
 Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}.
 
@@ -6121,7 +6127,7 @@ Consensus rules applying to a \spendDescription are given in \crossref{spenddesc
 
 
 \introsection
-\nsubsection{Encoding of \OutputDescriptions} \label{outputencoding}
+\subsection{Encoding of \OutputDescriptions} \label{outputencoding}
 
 Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}.
 
@@ -6161,7 +6167,7 @@ Consensus rules applying to an \outputDescription are given in \crossref{outputd
 
 
 \introsection
-\nsubsection{\BlockHeader} \label{blockheader}
+\subsection{\BlockHeader} \label{blockheader}
 
 The \Zcash \blockHeader format is as follows:
 
@@ -6284,7 +6290,7 @@ The changes relative to \Bitcoin version $4$ blocks as described in \cite{Bitc-B
 
 
 \introsection
-\nsubsection{Proof of Work}
+\subsection{Proof of Work}
 
 \Zcash uses Equihash \cite{BK2016} as its Proof of Work. Motivations for
 changing the Proof of Work from \SHAd used by \Bitcoin are described
@@ -6300,7 +6306,7 @@ A \block satisfies the Proof of Work if and only if:
 
 
 \introsection
-\nsubsubsection{Equihash} \label{equihash}
+\subsubsection{Equihash} \label{equihash}
 
 An instance of the Equihash algorithm is parameterized by positive integers $n$ and $k$,
 such that $n$ is a multiple of $k+1$. We assume $k \geq 3$.
@@ -6425,7 +6431,7 @@ ordering of bits in the solution encoding would require bit-reversal
 (as opposed to only shifting).
 }
 
-\nsubsubsection{Difficulty filter} \label{difficulty}
+\subsubsection{Difficulty filter} \label{difficulty}
 
 Let $\ToTarget$ be as defined in \crossref{nbits}.
 
@@ -6439,7 +6445,7 @@ byte order, which \MUST be less than or equal to the \targetThreshold given by
 $\ToTarget(\nBitsField)$.
 
 
-\nsubsubsection{Difficulty adjustment} \label{diffadjustment}
+\subsubsection{Difficulty adjustment} \label{diffadjustment}
 
 \Zcash uses a difficulty adjustment algorithm based on DigiShield v3/v4 \cite{DigiByte-PoW},
 with simplifications and altered parameters, to adjust difficulty to target
@@ -6510,7 +6516,7 @@ the given \blockHeight.
 }
 
 \introlist
-\nsubsubsection{nBits conversion} \label{nbits}
+\subsubsection{nBits conversion} \label{nbits}
 
 Deterministic conversions between a \targetThreshold and a ``compact" nBits value are not
 fully defined in the Bitcoin documentation \cite{Bitc-nBits}, and so we define them here:
@@ -6529,7 +6535,7 @@ fully defined in the Bitcoin documentation \cite{Bitc-nBits}, and so we define t
 \end{formulae}
 
 \introlist
-\nsubsubsection{Definition of Work} \label{workdef}
+\subsubsection{Definition of Work} \label{workdef}
 
 As explained in \crossref{blockchain}, a node chooses the ``best'' \blockchain
 visible to it by finding the chain of valid \blocks with the greatest total work.
@@ -6541,7 +6547,7 @@ in its \blockHeader is defined as $\floor{\hfrac{2^{256}}{\ToTarget(\nBits) + 1}
 
 
 \introlist
-\nsubsection{Calculation of Block Subsidy and Founders' Reward} \label{subsidies}
+\subsection{Calculation of Block Subsidy and Founders' Reward} \label{subsidies}
 
 \crossref{subsidyconcepts} defines the \blockSubsidy, \minerSubsidy, and \foundersReward.
 Their amounts in \zatoshi are calculated from the \blockHeight using
@@ -6567,7 +6573,7 @@ $\MaxBlockSubsidy$, and $\FoundersFraction$ are instantiated in \crossref{consta
 \end{formulae}
 
 \introsection
-\nsubsection{Payment of Founders' Reward} \label{foundersreward}
+\subsection{Payment of Founders' Reward} \label{foundersreward}
 
 The \foundersReward is paid by a \transparent output in the \coinbaseTransaction, to
 one of $\NumFounderAddresses$ \transparent addresses, depending on the \blockHeight.
@@ -6675,13 +6681,13 @@ as its $\scriptPubKey$.
 \end{pnotes}
 
 
-\nsubsection{Changes to the Script System} \label{scripts}
+\subsection{Changes to the Script System} \label{scripts}
 
 The \ScriptOP{CODESEPARATOR} opcode has been disabled. This opcode also no longer
 affects the calculation of signature hashes.
 
 
-\nsubsection{Bitcoin Improvement Proposals} \label{bips}
+\subsection{Bitcoin Improvement Proposals} \label{bips}
 
 In general, Bitcoin Improvement Proposals (BIPs) do not apply to \Zcash unless
 otherwise specified in this section.
@@ -6734,9 +6740,9 @@ and would require an RFC in order to do so.)
 
 
 \introsection
-\nsection{Differences from the Zerocash paper} \label{differences}
+\section{Differences from the Zerocash paper} \label{differences}
 
-\nsubsection{Transaction Structure} \label{trstructure}
+\subsection{Transaction Structure} \label{trstructure}
 
 \Zerocash introduces two new operations, which are described in
 the paper as new transaction types, in addition to the original
@@ -6760,7 +6766,7 @@ conditions, at some cost in distinguishability.
 \todo{Describe changes to signing.}
 
 
-\nsubsection{\Memos}
+\subsection{\Memos}
 
 \Zcash adds a \memo sent from the creator of a \joinSplitDescription to
 the recipient of each output \note. This feature is described in
@@ -6768,7 +6774,7 @@ more detail in \crossref{notept}.
 
 
 \introlist
-\nsubsection{Unification of Mints and Pours}
+\subsection{Unification of Mints and Pours}
 
 In the original \Zerocash protocol, there were two kinds of transaction
 relating to \shieldedNotes:
@@ -6813,7 +6819,7 @@ exact number of \shielded inputs and outputs, but dummy (zero-valued)
 outputs are still possible.
 }
 
-\nsubsection{Faerie Gold attack and fix} \label{faeriegold}
+\subsection{Faerie Gold attack and fix} \label{faeriegold}
 
 When a \shieldedNote is created in \Zerocash, the creator is
 supposed to choose a new $\NoteAddressRand$ value at random.
@@ -6952,7 +6958,7 @@ does not repeat for outputs of different \transactions in the same \blockchain.
 }
 
 
-\nsubsection{Internal hash collision attack and fix} \label{internalh}
+\subsection{Internal hash collision attack and fix} \label{internalh}
 
 The \Zerocash security proof requires that the composition of
 $\Commit{\NoteCommitRand}$ and $\Commit{\NoteCommitS}$ is a
@@ -7007,7 +7013,7 @@ is supported for \Sapling notes under the same conditions as in \Zerocash
 (by the protocol, not necessarily by \zcashd).
 }
 
-\nsubsection{Changes to PRF inputs and truncation} \label{truncation}
+\subsection{Changes to PRF inputs and truncation} \label{truncation}
 
 The format of inputs to the PRFs instantiated in \crossref{concreteprfs}
 has changed relative to \Zerocash. There is also a requirement for another PRF,
@@ -7086,7 +7092,7 @@ no need for truncation in the inputs to any of these hashes.
 \todo{check, especially $\CRHivk$ which has truncated output.}
 }
 
-\nsubsection{In-band secret distribution} \label{inbandrationale}
+\subsection{In-band secret distribution} \label{inbandrationale}
 
 \Zerocash specified ECIES (referencing Certicom's SEC 1 standard) as the
 encryption scheme used for the in-band secret distribution. This has been
@@ -7175,7 +7181,7 @@ to resist parallel brute force in the multi-user setting: \notsprout{for \Sprout
 $\AuthPrivate$ is $252$ bits, and $\TransmitPrivate$ is no shorter than $\AuthPrivate$.
 
 
-\nsubsection{Omission in \Zerocash security proof} \label{crprf}
+\subsection{Omission in \Zerocash security proof} \label{crprf}
 
 The abstract \Zerocash protocol requires $\PRFaddr{}$ only to be a PRF;
 it is not specified to be collision-resistant. This reveals a flaw in
@@ -7224,7 +7230,7 @@ constraint 1(b) of the \joinSplitStatement (see \crossref{sproutspendauthority})
 implies distinctness of $\AuthPublicOldX{1}$ and $\AuthPublicOldX{2}$, therefore
 distinct openings of the \noteCommitment when Condition I or II is violated.
 
-\nsubsection{Miscellaneous}
+\subsection{Miscellaneous}
 
 \begin{itemize}
     \item The paper defines a \note as $((\AuthPublic, \TransmitPublic), \Value,
@@ -7256,7 +7262,7 @@ distinct openings of the \noteCommitment when Condition I or II is violated.
 \end{itemize}
 
 
-\nsection{Acknowledgements}
+\section{Acknowledgements}
 
 The inventors of \Zerocash are Eli Ben-Sasson, Alessandro Chiesa,
 Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars
@@ -7289,7 +7295,7 @@ Daira Hopwood, Sean Bowe, and Jack Grigg.
 
 
 \introsection
-\nsection{Change History}
+\section{Change History}
 
 \subparagraph{2018.0-beta-14}
 
@@ -7814,7 +7820,7 @@ Daira Hopwood, Sean Bowe, and Jack Grigg.
 \end{itemize}
 
 
-\nsection{References}
+\section{References}
 
 \begingroup
 \hfuzz=2pt
@@ -7829,12 +7835,12 @@ Daira Hopwood, Sean Bowe, and Jack Grigg.
 \vspace{20ex}
 \appendix
 \phantomsection
-\addcontentsline{toc}{section}{\larger{\nstrut{Appendices}}}
+\addcontentsline{toc}{section}{\larger{Appendices}}
 {\Larger{\textbf{Appendices}}}
 
-\nsection{Circuit Design} \label{circuitdesign}
+\section{Circuit Design} \label{circuitdesign}
 
-\nsubsection{\QuadraticArithmeticPrograms}
+\subsection{\QuadraticArithmeticPrograms}
 
 \Sapling defines two circuits, Spend and Output, each implementing an abstract
 statement described in \crossref{spendstatement} and \crossref{outputstatement}
@@ -7862,7 +7868,7 @@ Here $\times$ and $\mult$ both represent multiplication in the field $\GF{\Param
 but we use $\times$ for multiplications corresponding to gates of the circuit,
 and $\mult$ for multiplications by constants in the terms of a \linearCombination.
 
-\nsubsection{Elliptic curve background} \label{ecbackground}
+\subsection{Elliptic curve background} \label{ecbackground}
 
 The circuit makes use of a twisted Edwards curve, $\JubjubCurve$, and also a
 Montgomery curve that is birationally equivalent to $\JubjubCurve$.
@@ -7940,7 +7946,7 @@ then there are no solutions for $x$.
 
 
 \introsection
-\nsubsection{Circuit Components}
+\subsection{Circuit Components}
 
 Each of the following sections describes how to implement a particular
 component of the circuit, and counts the number of constraints required.
@@ -7961,9 +7967,9 @@ to more closely match the implementation.
 
 
 \introsection
-\nsubsubsection{Operations on individual bits} \label{cctbitops}
+\subsubsection{Operations on individual bits} \label{cctbitops}
 
-\nsubsubsubsection{Boolean constraints} \label{cctboolean}
+\subsubsubsection{Boolean constraints} \label{cctboolean}
 
 A boolean constraint $b \in \bit$ can be implemented as:
 
@@ -7973,7 +7979,7 @@ A boolean constraint $b \in \bit$ can be implemented as:
 
 
 \introlist
-\nsubsubsubsection{Selection constraints} \label{cctselection}
+\subsubsubsection{Selection constraints} \label{cctselection}
 
 A selection constraint $b \bchoose x : y = z$, where $b \typecolon \bit$ has been
 boolean-constrained, can be implemented as:
@@ -7984,7 +7990,7 @@ boolean-constrained, can be implemented as:
 
 
 \introsection
-\nsubsubsubsection{Nonzero constraints} \label{cctnonzero}
+\subsubsubsection{Nonzero constraints} \label{cctnonzero}
 
 Since only nonzero elements of $\GF{\ParamS{r}}$ have a multiplicative inverse, the
 assertion $a \neq 0$ can be implemented by witnessing the inverse,
@@ -8004,7 +8010,7 @@ $a_\barerange{0}{n-1}$ are nonzero.
 
 
 \introsection
-\nsubsubsubsection{Exclusive-or constraints} \label{cctxor}
+\subsubsubsection{Exclusive-or constraints} \label{cctxor}
 
 An exclusive-or operation $a \xor b = c$, where $a, b \typecolon \bit$ are
 already boolean-constrained, can be implemented in one constraint as:
@@ -8018,9 +8024,9 @@ by checking the truth table of $(a, b)$.
 
 
 \introsection
-\nsubsubsection{Operations on multiple bits} \label{cctmultibitops}
+\subsubsection{Operations on multiple bits} \label{cctmultibitops}
 
-\nsubsubsubsection{[Un]packing modulo \rS} \label{cctmodpack}
+\subsubsubsection{[Un]packing modulo \rS} \label{cctmodpack}
 
 The operation of converting a field element, $a$, to a sequence of boolean
 variables $b_\barerange{0}{n-1} \typecolon \bitseq{n}$ such that
@@ -8069,7 +8075,7 @@ This can be implemented in one constraint:
 
 
 \introsection
-\nsubsubsubsection{Range check} \label{cctrange}
+\subsubsubsection{Range check} \label{cctrange}
 
 Let $a = \vsum{i=0}{n-1} a_i \mult 2^i$, and suppose we want to constrain
 $a \leq c$ for some \emph{constant} $c = \vsum{i=0}{n-1} c_i \mult 2^i$.
@@ -8106,9 +8112,9 @@ This costs $n + k - 1 - t$ constraints.
 
 
 \introsection
-\nsubsubsection{Elliptic curve operations} \label{cctelliptic}
+\subsubsection{Elliptic curve operations} \label{cctelliptic}
 
-\nsubsubsubsection{Checking that affine Edwards coordinates are on the curve} \label{cctedvalidate}
+\subsubsubsection{Checking that affine Edwards coordinates are on the curve} \label{cctedvalidate}
 
 To check that $(u, \varv)$ is a point on the Edwards curve, use:
 
@@ -8120,7 +8126,7 @@ To check that $(u, \varv)$ is a point on the Edwards curve, use:
 
 
 \introsection
-\nsubsubsubsection{Edwards [de]compression and validation} \label{ccteddecompressvalidate}
+\subsubsubsection{Edwards [de]compression and validation} \label{ccteddecompressvalidate}
 
 Define $\DecompressValidate \typecolon \CompressedEdwardsJubjub \rightarrow \AffineEdwardsJubjub$
 as follows:
@@ -8156,7 +8162,7 @@ on the elliptic curve arithmetic in some cases.
 
 
 \introlist
-\nsubsubsubsection{Edwards \lrarrow\ Montgomery conversion} \label{cctconversion}
+\subsubsubsection{Edwards \lrarrow\ Montgomery conversion} \label{cctconversion}
 
 Define $\EdwardsToMont \typecolon \AffineEdwardsJubjub \rightarrow \AffineMontJubjub$
 as follows:
@@ -8229,7 +8235,7 @@ isomorphic $y$-coordinate rescaling of the \jubjubCurve.)
 
 
 \introsection
-\nsubsubsubsection{Affine-Montgomery arithmetic} \label{cctmontarithmetic}
+\subsubsubsection{Affine-Montgomery arithmetic} \label{cctmontarithmetic}
 
 The incomplete affine-Montgomery addition formulae given in
 \cite[section 4.3.2]{BL2017} are:
@@ -8302,7 +8308,7 @@ is not the point $(0, 0)$ (the only point of order $2$), as proven in
 
 
 \introlist
-\nsubsubsubsection{Affine-Edwards arithmetic} \label{cctedarithmetic}
+\subsubsubsection{Affine-Edwards arithmetic} \label{cctedarithmetic}
 
 Formulae for affine-Edwards addition are given in \cite[section 6]{BBJLP2008}.
 With a change of variable names to match our convention, the formulae for
@@ -8356,7 +8362,7 @@ $(u, \varv) = (u_1, \varv_1) = (u_2, \varv_2)$ and observing that $u \mult \varv
 
 
 \introsection
-\nsubsubsubsection{Affine-Edwards nonsmall-order check} \label{cctednonsmallorder}
+\subsubsubsection{Affine-Edwards nonsmall-order check} \label{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
@@ -8408,7 +8414,7 @@ The total cost, including the curve check, is $3 + 3 + 2 = 8$ constraints.
 
 
 \introsection
-\nsubsubsubsection{Fixed-base affine-Edwards scalar multiplication} \label{cctfixedscalarmult}
+\subsubsubsection{Fixed-base affine-Edwards scalar multiplication} \label{cctfixedscalarmult}
 
 If the base point $B$ is fixed for a given scalar multiplication $\scalarmult{k}{B}$,
 we can fully precompute window tables for each window position.
@@ -8457,7 +8463,7 @@ the additional complexity was not considered justified for \Sapling.
 
 
 \introsection
-\nsubsubsubsection{Variable-base affine-Edwards scalar multiplication} \label{cctvarscalarmult}
+\subsubsubsection{Variable-base affine-Edwards scalar multiplication} \label{cctvarscalarmult}
 
 When the base point $B$ is not fixed, the method in the preceding section
 cannot be used. Instead we use a naïve double-and-add method.
@@ -8496,7 +8502,7 @@ considered justified for \Sapling.
 
 
 \introsection
-\nsubsubsubsection{Pedersen hash} \label{cctpedersenhash}
+\subsubsubsection{Pedersen hash} \label{cctpedersenhash}
 
 The specification of the \xPedersenHashes used in \Sapling is given in
 \crossref{concretepedersenhash}. It is based on the scheme from
@@ -8631,7 +8637,7 @@ for the Merkle tree hashes $\ell = 516$, so the cost is ... constraints.
 
 
 \introlist
-\nsubsubsubsection{Mixing Pedersen hash} \label{cctmixinghash}
+\subsubsubsection{Mixing Pedersen hash} \label{cctmixinghash}
 
 A mixing \xPedersenHash is used to compute $\NoteAddressRand$ from
 $\cm$ and $\NotePosition$ in \crossref{commitmentsandnullifiers}. It takes as
@@ -8650,7 +8656,7 @@ Edwards addition, for a total of \todo{...} constraints.
 
 
 \introsection
-\nsubsubsection{Merkle path check} \label{cctmerklepath}
+\subsubsection{Merkle path check} \label{cctmerklepath}
 
 Checking a Merkle authentication path, as described in \crossref{merklepath},
 requires to:
@@ -8687,7 +8693,7 @@ uses of $c_1$. The \Sapling circuit does not use this optimization.}
 
 
 \introsection
-\nsubsubsection{\WindowedPedersenCommitment} \label{cctwindowedcommit}
+\subsubsection{\WindowedPedersenCommitment} \label{cctwindowedcommit}
 
 We construct \windowedPedersenCommitments by reusing the Pedersen hash
 implementation, and adding a randomized point:
@@ -8708,7 +8714,7 @@ This can be implemented in:
 for a total of $... \smult \ell + 756$ constraints.
 
 
-\nsubsubsection{\HomomorphicPedersenCommitment} \label{ccthomomorphiccommit}
+\subsubsection{\HomomorphicPedersenCommitment} \label{ccthomomorphiccommit}
 
 The \windowedPedersenCommitments defined in the preceding section are
 highly efficient, but they do not support the homomorphic property we
@@ -8731,7 +8737,7 @@ This can be straightforwardly implemented in ... constraints.
 
 
 \introsection
-\nsubsubsection{BLAKE2s hashes} \label{cctblake2s}
+\subsubsection{BLAKE2s hashes} \label{cctblake2s}
 
 $\BlakeTwosGeneric$ is defined in \cite{ANWW2013}. Its main subcomponent is a
 ``$G$ function'', defined as follows:
@@ -8776,7 +8782,7 @@ cryptanalytic attention to confidently use them for \Sapling.
 
 
 \introsection
-\nsubsection{The SaplingSpend circuit} \label{cctsaplingspend}
+\subsection{The SaplingSpend circuit} \label{cctsaplingspend}
 
 \begin{formulae}
   \item ...
@@ -8784,7 +8790,7 @@ cryptanalytic attention to confidently use them for \Sapling.
 
 
 \introsection
-\nsubsection{The SaplingOutput circuit} \label{cctsaplingoutput}
+\subsection{The SaplingOutput circuit} \label{cctsaplingoutput}
 
 \begin{formulae}
   \item ...