Improve pagination.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

protocol/protocol.tex

@@ -15,6 +15,8 @@
 \RequirePackage{hhline}
 \RequirePackage[usestackEOL]{stackengine}
 \RequirePackage{comment}
+\RequirePackage{needspace}
+\RequirePackage[nobottomtitles]{titlesec}
 
 \RequirePackage[style=alphabetic,maxbibnames=99,dateabbrev=false,urldate=iso8601,backref=true,backrefstyle=none,backend=biber]{biblatex}
 \addbibresource{zcash.bib}
@@ -57,12 +59,18 @@
 \setlength{\textwidth}{7in}
 \setlength{\topmargin}{-0.75in}
 \setlength{\textheight}{9.2in}
-\setlength{\parskip}{1.5ex}
 \setlength{\parindent}{0ex}
 \renewcommand{\arraystretch}{1.4}
 \overfullrule=2cm
 
-\setlist[itemize]{itemsep=0.5ex,topsep=0.2ex,after=\vspace{1.5ex}}
+\renewcommand{\bottomtitlespace}{8ex}
+
+% Use rubber lengths between paragraphs to improve default pagination.
+% https://tex.stackexchange.com/questions/17178/vertical-spacing-pagination-and-ideal-results
+\setlength{\parskip}{1.5ex plus 1pt minus 1pt}
+
+\setlist[enumerate]{before=\vspace{-1ex}}
+\setlist[itemize]{itemsep=0.5ex,topsep=0.2ex,before=\vspace{-1ex},after=\vspace{1.5ex}}
 
 \newlist{formulae}{itemize}{3}
 \setlist[formulae]{itemsep=0.2ex,topsep=0ex,leftmargin=1.5em,label=,before=\vspace{-1ex},after=\vspace{1.5ex}}
@@ -92,6 +100,8 @@
 \newcommand{\nsubsection}[1]{\subsection{\nstrut{#1}}}
 \newcommand{\nsubsubsection}[1]{\subsubsection{\nstrut{#1}}}
 
+\newcommand{\introlist}{\needspace{15ex}}
+
 \mathchardef\mhyphen="2D
 
 % http://tex.stackexchange.com/a/309445/78411
@@ -632,12 +642,12 @@
 \newcommand{\EnforceCommit}[1]{\mathsf{enforce}_{#1}}
 
 
-\newcommand{\consensusrule}[1]{\subparagraph{Consensus rule:}{#1}}
+\newcommand{\consensusrule}[1]{\needspace{3ex}\subparagraph{Consensus rule:}{#1}}
-\newenvironment{consensusrules}{\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}}
+\newenvironment{consensusrules}{\introlist\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}}
-\newcommand{\securityrequirement}[1]{\subparagraph{Security requirement:}{#1}}
+\newcommand{\securityrequirement}[1]{\needspace{3ex}\subparagraph{Security requirement:}{#1}}
-\newenvironment{securityrequirements}{\subparagraph{Security requirements:}\begin{itemize}}{\end{itemize}}
+\newenvironment{securityrequirements}{\introlist\subparagraph{Security requirements:}\begin{itemize}}{\end{itemize}}
 \newcommand{\pnote}[1]{\subparagraph{Note:}{#1}}
-\newenvironment{pnotes}{\subparagraph{Notes:}\begin{itemize}}{\end{itemize}}
+\newenvironment{pnotes}{\introlist\subparagraph{Notes:}\begin{itemize}}{\end{itemize}}
 
 
 \begin{document}
@@ -678,6 +688,8 @@ document are to be interpreted as described in \cite{RFC-2119} when they
 appear in \ALLCAPS. These words may also appear in this document in
 lower case as plain English words, absent their normative meanings.
 
+\vspace{2ex}
+\introlist
 This specification is structured as follows:
 
 \begin{itemize}
@@ -737,6 +749,7 @@ this \spendingKey. An unspent valid \note, at a given point on the \blockchain,
 is one for which the \noteCommitment has been publically revealed on the
 \blockchain prior to that point, but the \nullifier has not.
 
+\introlist
 A \transaction can contain \transparent inputs, outputs, and scripts, which all
 work as in \Bitcoin \cite{Bitcoin-Protocol}. It also contains a sequence of zero or
 more \joinSplitDescriptions. Each of these describes a \joinSplitTransfer\hairspace\footnote{
@@ -940,6 +953,7 @@ an adversary would have to know $\TransmitPublic$ in order to exploit a
 hypothetical weakness in that cryptosystem.
 }
 
+\needspace{20ex}
 \nsubsection{\Notes}
 
 A \note (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value,
@@ -1022,6 +1036,7 @@ a \noteCommitmentTree state given the assumed security properties of the Merkle
 hash function. Since the \nullifierSet is always updated together with the
 \noteCommitmentTree, this also identifies a particular state of the \nullifierSet.
 
+\introlist
 In a given node's \blockchainview, \treestates are chained as follows:
 
 \begin{itemize}
@@ -1150,6 +1165,7 @@ the Equihash parameters $n$ and $k$, are written subscripted.
 It is instantiated in \crossref{equihashgen}.
 }
 
+\introlist
 \nsubsubsection{\PseudoRandomFunctions} \label{abstractprfs}
 
 $\PRF{x}{}$ is a \pseudoRandomFunction keyed by $x$. \changed{Four} \emph{independent}
@@ -1251,6 +1267,7 @@ independently at random from $\KAPrivate$.
 
 Let $\TransmitPublicSup{j} := \KADerivePublic(\TransmitPrivateSup{j})$.
 
+\introlist
 An adversary can adaptively query a function
 $Q \typecolon \range{1}{2} \times \hSigType \rightarrow
 \KAPublic \times \Keyspace_{\allNew}$ where $Q_j(\hSig)$ is defined as follows:
@@ -1279,6 +1296,7 @@ This is not considered to be a significant security weakness.
 }
 
 
+\introlist
 \nsubsubsection{Signatures} \label{abstractsig}
 
 A signature scheme $\Sig$ defines:
@@ -1329,10 +1347,12 @@ pair without access to the signing key.
 \end{pnotes}
 
 
+\introlist
 \nsubsubsection{Commitment} \label{abstractcomm}
 
 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:
+
 \begin{itemize}
   \item no information is revealed about it without the \trapdoor (``hiding''),
   \item given the \trapdoor and input, the commitment can be verified to ``open''
@@ -1357,6 +1377,7 @@ in zero knowledge --- that is, without revealing information about the
 \auxiliaryInputs other than that implied by the \statement. The type of
 \zeroKnowledgeProvingSystem needed by \Zcash is a \ppzkSNARK.
 
+\introlist
 A \ppzkSNARK instance $\ZK$ defines:
 
 \begin{itemize}
@@ -1414,6 +1435,7 @@ Let $\KA$ be a \keyAgreementScheme, instantiated in \crossref{concretekeyagreeme
 A new \spendingKey $\AuthPrivate$ is generated by choosing a bit string
 uniformly at random from $\bitseq{\AuthPrivateLength}$.
 
+\introlist
 \changed{
 $\AuthPublic$, $\TransmitPrivate$ and $\TransmitPublic$ are derived from
 $\AuthPrivate$
@@ -1437,6 +1459,7 @@ Each \transaction includes a sequence of zero or more \joinSplitDescriptions.
 When this sequence is non-empty, the \transaction also includes encodings of a
 $\JoinSplitSig$ public verification key and signature.
 
+\introlist
 Each \joinSplitDescription consists of $(\vpubOld, \vpubNew, \rt,
 \nfOld{\allOld}, \cmNew{\allNew}, \EphemeralPublic, \RandomSeed,
 \h{\allOld}, \JoinSplitProof, \TransmitCiphertext{\allNew})$
@@ -1472,6 +1495,7 @@ where
 
 The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \notesCiphertext.
 
+\introlist
 The value $\hSig$ is also computed from \changed{$\RandomSeed$, $\nfOld{\allOld}$, and} the
 $\joinSplitPubKey$ of the containing \transaction:
 
@@ -1491,6 +1515,7 @@ $\hSigCRH$ is instantiated in \crossref{hsigcrh}.
         \vpubOld, \vpubNew, \hSig, \h{\allOld}), \Proof_{\JoinSplit}) = 1$.
 \end{consensusrules}
 
+\introlist
 \nsubsection{Sending \Notes} \label{send}
 
 In order to send \shielded value, the sender constructs a \transaction
@@ -1501,12 +1526,14 @@ a new $\JoinSplitSig$ key pair:
   \item $(\joinSplitPrivKey, \joinSplitPubKey) \leftarrowR \JoinSplitSigGen()$.
 \end{formulae}
 
+\introlist
 For each \joinSplitDescription, the sender chooses $\RandomSeed$ uniformly at
 random on $\bitseq{\RandomSeedLength}$, and selects
 the input \notes. At this point there is sufficient information to compute $\hSig$,
 as described in the previous section. \changed{The sender also chooses $\NoteAddressPreRand$
 uniformly at random on $\bitseq{\NoteAddressPreRandLength}$.}
 Then it creates each output \note with index $i \typecolon \setofNew$ as follows:
+
 \begin{itemize}
   \item Choose $\NoteCommitRandNew{i}$ uniformly at random on $\bitseq{\NoteCommitRandLength}$.
 \changed{
@@ -1522,6 +1549,7 @@ of the input \notes and of the output \notes. Other considerations relating to
 information leakage from the structure of \transactions are beyond the
 scope of this specification.
 
+\introlist
 After generating all of the \joinSplitDescriptions, the sender obtains the
 $\dataToBeSigned$ (\crossref{nonmalleability}), and signs it with
 the private \joinSplitSigningKey:
@@ -1539,9 +1567,11 @@ The fields in a \joinSplitDescription allow for $\NOld$ input \notes, and
 $\NNew$ output \notes. In practice, we may wish to encode a \joinSplitTransfer
 with fewer input or output \notes. This is achieved using \dummyNotes.
 
+\introlist
 \changed{
 A \dummy input \note, with index $i$ in the \joinSplitDescription, is constructed
 as follows:
+
 \begin{itemize}
   \item Generate a new random \spendingKey $\AuthPrivateOld{i}$ and derive its
         \payingKey $\AuthPublicOld{i}$.
@@ -1578,6 +1608,7 @@ When a \noteCommitment is added to the tree, it occupies the \merkleLeafNode
 It is assumed to be infeasible to find a preimage \note $\NoteTuple{}$ such that
 $\NoteCommit(\NoteTuple{}) = \Uncommitted$.
 
+\introlist
 The \merkleNodes at \merkleLayers $0$ to $\MerkleDepth-1$ inclusive are called
 \merkleInternalNodes, and are associated with $\MerkleCRH$ outputs.
 \MerkleInternalNodes are computed from their children in the next \merkleLayer
@@ -1587,6 +1618,7 @@ as follows: for $0 \leq h < \MerkleDepth$ and $0 \leq i < 2^h$,
   \item $\MerkleNode{h}{i} := \MerkleCRH(\MerkleNode{h+1}{2i}, \MerkleNode{h+1}{2i+1})$.
 \end{formulae}
 
+\introlist
 A \merklePath from \merkleLeafNode $\MerkleNode{\MerkleDepth}{i}$ in the
 \incrementalMerkleTree is the sequence
 
@@ -1679,6 +1711,7 @@ exists in the set.
 
 \nsubsection{\JoinSplitStatement} \label{jsstatement}
 
+\introlist
 A valid instance of $\JoinSplitProof$ assures that given a \term{primary input}:
 
 \begin{formulae}
@@ -1692,6 +1725,7 @@ A valid instance of $\JoinSplitProof$ assures that given a \term{primary input}:
             \h{\allOld} \typecolon \typeexp{\PRFOutput}{\NOld})$,
 \end{formulae}
 
+\introlist
 the prover knows an \term{auxiliary input}:
 
 \begin{formulae}
@@ -1704,6 +1738,7 @@ the prover knows an \term{auxiliary input}:
             \EnforceCommit{\allOld} \typecolon \bitseq{\NOld}})$,
 \end{formulae}
 
+\introlist
 where:
 
 \begin{formulae}
@@ -1713,6 +1748,7 @@ where:
 \vNew{i}, \NoteAddressRandNew{i}, \NoteCommitRandNew{i})$
 \end{formulae}
 
+\introlist
 such that the following conditions hold:
 
 \subparagraph{Merkle path validity} \label{merklepathvalidity}
@@ -1776,7 +1812,9 @@ the original \note \changed{ and \memo}.
 
 All of the resulting ciphertexts are combined to form a \notesCiphertext.
 
+\introlist
 For both encryption and decryption,
+
 \begin{itemize}
   \item Let $\Sym$ be the \encryptionScheme instantiated in \crossref{concretesym}.
   \item Let $\KDF$ be the \keyDerivationFunction instantiated in \crossref{concretekdf}.
@@ -1791,7 +1829,9 @@ for the intended recipient addresses of each new \note.
 
 Let $\NotePlaintext{\allNew}$ be the \notePlaintexts as defined in \crossref{notept}.
 
+\introlist
 Then to encrypt:
+
 \begin{itemize}
 \changed{
   \item Generate a new $\KA$ (public, private) key pair
@@ -1829,6 +1869,7 @@ Let $\PaymentAddress = (\AuthPublic, \TransmitPublic)$ be the recipient's
 
 Let $\cmNew{\allNew}$ be the \noteCommitments of each output coin.
 
+\introlist
 Then for each $i \in \setofNew$, the recipient will attempt to decrypt that ciphertext
 component as follows:
 
@@ -1841,6 +1882,7 @@ component as follows:
 \AuthPublic).$
 \end{itemize}
 
+\introlist
 $\DecryptNote(\TransmitKey{i}, \TransmitCiphertext{i}, \cmNew{i}, \AuthPublic)$
 is defined as follows:
 
@@ -1951,6 +1993,7 @@ For example, the following diagrams are all equivalent:
 and represent the byte sequence $[\hexint{D2}, \hexint{BC}, \hexint{3A}, \hexint{12}]$.
 \end{comment}
 
+\introlist
 \nsubsection{Constants} \label{constants}
 
 Define:
@@ -1976,6 +2019,7 @@ Define:
 \end{formulae}
 
 
+\introlist
 \nsubsection{Concrete Cryptographic Functions}
 
 \nsubsubsection{Merkle Tree Hash Function} \label{merklecrh}
@@ -2006,6 +2050,7 @@ $\SHA$ must be collision-resistant, and it must be infeasible to find a preimage
 such that $\SHA(x) = \zeros{256}$.
 }
 
+\introlist
 \nsubsubsection{\hSigText{} Hash Function} \label{hsigcrh}
 
 \newsavebox{\hsigbox}
@@ -2043,6 +2088,7 @@ block.
 $\Blake{256}(\ascii{ZcashComputehSig}, x)$ must be collision-resistant.
 }
 
+\introlist
 \nsubsubsection{Equihash Generator} \label{equihashgen}
 
 $\EquihashGen{n, k}$ is a specialized hash function that maps an input
@@ -2069,6 +2115,7 @@ Let $\powtag := \Justthebox{\powtagbox}$.
 Let $\powcount(g) := \Justthebox{\powcountbox}$.
 
 \vspace{2ex}
+\introlist
 % Blech. Dijkstra was right \cite{EWD831}.
 Let $\EquihashGen{n, k}(S, i) := T_{h+1\hairspace..\hairspace h+n}$, where
 \begin{formulae}
@@ -2098,6 +2145,7 @@ the number of calls to $\BlakeGeneric$ can be reduced by a factor of $\floor{\fr
 in the best case (which is a factor of 2 for $n = 200$).
 }
 
+\introlist
 \nsubsubsection{\PseudoRandomFunctions} \label{concreteprfs}
 
 The \changed{four} independent PRFs described in \crossref{abstractprfs} are
@@ -2242,6 +2290,7 @@ Define $\KAFormatPrivate(x) := \Clamp(x)$.
 Define $\KAAgree(n, q) := \CurveMultiply(n, q)$.
 }
 
+\introlist
 \nsubsubsection{\KeyDerivation} \label{concretekdf}
 
 \newsavebox{\kdftagbox}
@@ -2309,6 +2358,7 @@ $\JoinSplitSigSpecific$ is defined as using $\JoinSplitSigHashName$ internally.
 \end{bytefield}
 \end{lrbox}
 
+\introlist
 \changed{
 The encoding of a signature is:
 }
@@ -2322,6 +2372,7 @@ where $\EdDSAR$ and $\EdDSAS$ are as defined in \cite{BDL+2012}.
 The encoding of a public key is as defined in \cite{BDL+2012}.
 }
 
+\introlist
 \nsubsubsection{Commitment} \label{concretecomm}
 
 \newsavebox{\cmbox}
@@ -2372,8 +2423,10 @@ $(\Value, \NoteAddressRand, \NoteCommitRand\changed{, \Memo})$.
 The first three of these fields are as defined earlier.
 \changed{$\Memo$ is a 512-byte \memo associated with this \note.
 
+\introlist
 The usage of the \memo is by agreement between the sender and recipient of the
 \note. The \memo{} \SHOULD be encoded either as:
+
 \begin{itemize}
   \item a UTF-8 human-readable string \cite{Unicode}, padded by appending zero bytes; or
   \item an arbitrary sequence of 512 bytes starting with a byte value of $\hexint{F5}$
@@ -2391,7 +2444,9 @@ A start byte of $\hexint{F6}$ or greater is reserved for use in future \Zcash
 protocol extensions.
 }
 
+\introlist
 The encoding of a \notePlaintext consists of, in order:
+
 \begin{equation*}
 \begin{bytefield}[bitwidth=0.029em]{1608}
 \changed{
@@ -2436,6 +2491,7 @@ The language consisting of the following encoding possibilities is prefix-free.
 \xTransparent payment addresses are either P2SH (Pay to Script Hash) \cite{BIP-13}
 or P2PKH (Pay to Public Key Hash) \cite{Bitcoin-P2PKH} addresses.
 
+\introlist
 The raw encoding of a P2SH address consists of:
 
 \begin{equation*}
@@ -2455,6 +2511,7 @@ The raw encoding of a P2SH address consists of:
   \item 160 bits specifying a script hash \cite{Bitcoin-P2SH}.
 \end{itemize}
 
+\introlist
 The raw encoding of a P2PKH address consists of:
 
 \begin{equation*}
@@ -2501,6 +2558,7 @@ $\TransmitPublic$ is a $\KAPublic$ key (see \crossref{concretekeyagreement}),
 for use with the encryption scheme defined in \crossref{inband}. These
 components are derived from a \spendingKey as described in \crossref{keycomponents}.
 
+\introlist
 The raw encoding of a \paymentAddress consists of:
 
 \begin{equation*}
@@ -2538,6 +2596,7 @@ cause the first two characters of the Base58Check encoding to be fixed as
 A \spendingKey consists of $\AuthPrivate$, which is a sequence of \changed{252} bits
 (see \crossref{keycomponents}).
 
+\introlist
 The raw encoding of a \spendingKey consists of, in order:
 
 \begin{equation*}
@@ -2589,6 +2648,7 @@ the systems in \cite{PGHR2013} and \cite{BCGTV2013}.
 
 The pairing implementation is $\BNImpl$.
 
+\introlist
 Let $q = 21888242871839275222246405745257275088696311157297823662689037894645226208583$.
 
 Let $r = 21888242871839275222246405745257275088548364400416034343698204186575808495617$.
@@ -2597,7 +2657,9 @@ Let $b = 3$.
 
 ($q$ and $r$ are prime.)
 
+\introlist
 The pairing is of type $\GroupG{1} \times \GroupG{2} \rightarrow \GroupG{T}$, where:
+
 \begin{itemize}
   \item $\GroupG{1}$ is a Barreto--Naehrig curve over $\GF{q}$ with equation
 $y^2 = x^3 + b$. This curve has embedding degree 12 with respect to $r$.
@@ -2609,6 +2671,7 @@ irreducible polynomial $t^2 + 1$.
 $\GFstar{q^{12}}$.
 \end{itemize}
 
+\introlist
 Let $\PointP{1} \typecolon \GroupG{1} = (1, 2)$.
 
 \begin{tabular}{@{}l@{}r@{}l@{}}
@@ -2681,7 +2744,9 @@ Define $\ItoOSP{} \typecolon (k \typecolon \Nat) \times \range{0}{256^k\!-\!1} \
 \typeexp{\range{0}{255}}{k}$ such that $\ItoOSP{\ell}(n)$ is the sequence of $\ell$ bytes
 representing $n$ in big-endian order.
 
+\introlist
 For a point $P \typecolon \GroupG{1} = (x_P, y_P)$:
+
 \begin{itemize}
   \item The field elements $x_P$ and $y_P \typecolon \GF{q}$ are represented as
         integers $x$ and $y \typecolon \range{0}{q\!-\!1}$.
@@ -2689,7 +2754,9 @@ For a point $P \typecolon \GroupG{1} = (x_P, y_P)$:
   \item $P$ is encoded as $\Justthebox{\gonebox}$.
 \end{itemize}
 
+\introlist
 For a point $P \typecolon \GroupG{2} = (x_P, y_P)$:
+
 \begin{itemize}
   \item A field element $w \typecolon \GF{q^2}$ is represented as
         a polynomial $a_{w,1} \mult t + a_{w,0} \typecolon \GF{q}[t]$ modulo $t^2 + 1$.
@@ -2703,7 +2770,9 @@ For a point $P \typecolon \GroupG{2} = (x_P, y_P)$:
   \item $P$ is encoded as $\Justthebox{\gtwobox}$.
 \end{itemize}
 
+\introlist
 \subparagraph{Non-normative notes:}
+
 \begin{itemize}
   \item The use of big-endian byte order is different from the encoding
         of most other integers in this protocol. The above encodings are consistent
@@ -2722,6 +2791,7 @@ When computing square roots in $\GF{q}$ or $\GF{q^2}$ in order to decompress
 a point encoding, the implementation \MUSTNOT assume that the square root
 exists, or that the encoding represents a point on the curve.
 
+\introlist
 \nsubsubsection{Encoding of \ZeroKnowledgeProofs} \label{proofencoding}
 
 \newsavebox{\proofbox}
@@ -2748,9 +2818,10 @@ A proof is encoded by concatenating the encodings of its elements:
 The resulting proof size is 296 bytes.
 
 \vspace{0.8ex}
-
+\introlist
 In addition to the steps to verify a proof given in \cite[Appendix B]{BCTV2015}, the
 verifier \MUST check, for the encoding of each element, that:
+
 \begin{itemize}
   \item the lead byte is of the required form;
   \item the remaining bytes encode a big-endian representation of an integer
@@ -2760,6 +2831,7 @@ verifier \MUST check, for the encoding of each element, that:
         the subgroup $\GroupG{2}$).
 \end{itemize}
 
+\introlist
 \nsubsection{\JoinSplitParameters} \label{jsparameters}
 
 For the \Zcash production \blockchain and testnet, the $\FullHashName$ hashes of the
@@ -2774,6 +2846,7 @@ format, are:
 These parameters were obtained by a multi-party computation described in \cite{GitHub-mpc}.
 
 
+\needspace{30ex}
 \nsection{Consensus Changes from \Bitcoin}
 
 \nsubsection{Encoding of \Transactions} \label{txnencoding}
@@ -2822,7 +2895,9 @@ $\versionField > 1$ and $\nJoinSplit > 0$.
 The encoding of $\joinSplitPubKey$ and the data to be signed are specified in
 \crossref{nonmalleability}.
 
+\introlist
 The changes relative to \Bitcoin version 1 transactions as described in \cite{Bitcoin-Format} are:
+
 \begin{itemize}
   \item The \transactionVersionNumber{} can be either 1 or 2. A version 1 \transaction is
         equivalent to a version 2 \transaction with $\nJoinSplit = 0$. Software that parses
@@ -2843,6 +2918,7 @@ it is associated with support for \ScriptOP{CHECKSEQUENCEVERIFY} as specified in
 9, 112 and 113.
 }
 
+\introlist
 \nsubsection{Encoding of \JoinSplitDescriptions} \label{joinsplitencoding}
 
 An abstract \joinSplitDescription, as described in \crossref{joinsplit}, is encoded in
@@ -2938,7 +3014,9 @@ according to \crossref{equihash}. \\ \hline
 \end{tabularx}
 \end{center}
 
+\introlist
 The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-Block} are:
+
 \begin{itemize}
   \item The \blockVersionNumber{} \MUST be 4. Previous versions are not supported. Software
         that parses blocks \MUSTNOT assume, when an encoded \block starts with an $\nVersion$
@@ -2964,7 +3042,9 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-
 changing the Proof of Work from \SHAd used by \Bitcoin are described
 in \cite{WG2016}.
 
+\introlist
 A \block satisfies the Proof of Work if and only if:
+
 \begin{itemize}
   \item The $\solution$ field encodes a \validEquihashSolution according to \crossref{equihash}.
   \item The \blockHeader satisfies the difficulty check according to \crossref{difficulty}.
@@ -2982,6 +3062,7 @@ The Generalized Birthday Problem is defined as follows: given a sequence
 $X_{1..\mathrm{N}}$ of $n$-bit strings, find $2^k$ distinct $X_{i_j}$ such that
 $\vxor{j=1}{2^k} X_{i_j} = 0$.
 
+\introlist
 In Equihash, $\mathrm{N} = 2^{\frac{n}{k+1}+1}$, and the sequence $X_{1..\mathrm{N}}$ is
 derived from the \blockHeader and a nonce:
 
@@ -3017,6 +3098,7 @@ $\vxor{j=1}{2^k} X_{i_j} = 0$.
 
 \subparagraph{Algorithm Binding conditions}
 
+\introlist
 For all $r \in \range{1}{k\!-\!1}$, for all $w \in \range{0}{2^{k-r}\!-\!1}$:
 \begin{itemize}
   \item $\vxor{j=1}{2^r} X_{i_{w \mult 2^r + j}}$ has $\frac{n \mult r}{k+1}$ leading zeroes; and
@@ -3028,6 +3110,7 @@ This does not include a difficulty condition, because here we are defining valid
 of an Equihash solution independent of difficulty.
 }
 
+\introlist
 An Equihash solution with $n = 200$ and $k = 9$ is encoded in the $\solution$
 field of a \blockHeader as follows:
 
@@ -3067,7 +3150,7 @@ field of a \blockHeader as follows:
   \item $\Justthebox{\solutionbox}$
 \end{formulae}
 
-\vspace{1ex}
+\introlist
 Recall from \crossref{boxnotation} that bits in the above diagram are
 ordered from most to least significant in each byte.
 For example, if the first 3 elements of $i$ are $[69, 42, 2^{21}]$,
@@ -3136,6 +3219,7 @@ one of $\NumFounderAddresses$ \transparent addresses, depending on the \blockHei
 
 \renewcommand{\arraystretch}{0.95}
 
+\introlist
 For the production network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddresses}$ is:
 
 \begin{tabular}{@{\hskip 2.5em}l@{\;}l}
@@ -3165,6 +3249,7 @@ For the production network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddress
  & \ascii{t3R3Y5vnBLrEn8L6wFjPjBLnxSUQsKnmFpv}, \ascii{t3Pcm737EsVkGTbhsu2NekKtJeG92mvYyoN}\, ]
 \end{tabular}
 
+\introlist
 For the test network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddresses}$ is:
 
 \begin{tabular}{@{\hskip 2.5em}l@{\;}l}
@@ -3201,6 +3286,7 @@ P2SH multisig address.
 
 Let $\SlowStartShift$ be defined as in the previous section.
 
+\introlist
 Define:
 
 \begin{formulae}
@@ -3325,10 +3411,12 @@ the recipient of each output \note. This feature is described in
 more detail in \crossref{notept}.
 
 
+\introlist
 \nsubsection{Unification of Mints and Pours}
 
 In the original \Zerocash protocol, there were two kinds of transaction
 relating to \shieldedNotes:
+
 \begin{itemize}
   \item a ``Mint'' transaction takes value from \transparent UTXOs as
 input and produces a new \shieldedNote as output.
@@ -3375,6 +3463,7 @@ legends in which faeries pay mortals in what appears to be gold,
 but which soon after reveals itself to be leaves, gorse blossoms,
 gingerbread cakes, or other less valuable things \cite{LG2004}.
 
+\introlist
 This attack does not violate the security definitions given in
 \cite{BCG+2014}. The issue could be framed as a problem
 either with the definition of Completeness, or the definition of
@@ -3489,9 +3578,11 @@ to 254 bits in the input to $\PRFsn{}$ (which corresponds to $\PRFnf{}$ in \Zcas
 Also, $\hSig$ is truncated from 256 to 253 bits in the input to $\PRFpk{}$.
 These truncations are not taken into account in the security proofs.
 
+\introlist
 Both truncations affect the validity of the proof sketch for Lemma D.2 in
 the proof of Ledger Indistinguishability in \cite[Appendix D]{BCG+2014}.
 In more detail:
+
 \begin{itemize}
   \item In the argument relating $\mathbf{H}$ and $\Game_2$, it is stated that in $\Game_2$,
         ``for each $i \in \setof{1, 2}, \mathsf{sn}_i := \PRFsn{\AuthPrivate}(\NoteAddressRand)$
@@ -3549,6 +3640,7 @@ changed to a scheme based on Curve25519 key agreement, and the authenticated
 encryption algorithm $\SymSpecific$. This scheme is still loosely based on ECIES,
 and on the $\CryptoBoxSeal$ scheme defined in libsodium \cite{libsodium-Seal}.
 
+\introlist
 The motivations for this change were as follows:
 
 \begin{itemize}
@@ -3633,6 +3725,7 @@ The \joinSplitStatements are still valid because they can only
 check that the $\AuthPrivate$ in the witness is \emph{some} preimage of
 the $\AuthPublic$ used in the \noteCommitment.
 
+\introlist
 The error is in the proof of Balance in \cite[Appendix D.3]{BCG+2014}.
 For the ``$\Adversary$ violates Condition I'' case, the proof says:
 
@@ -3717,6 +3810,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
 \crossref{truncation} were also found by Daira Hopwood.
 
 
+\introlist
 \nsection{Change history}
 
 \subparagraph{2016.0-beta-1.13}
@@ -3725,6 +3819,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Define $\PRFaddr{}$ in \crossref{keycomponents}.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.12}
 
 \begin{itemize}
@@ -3734,6 +3829,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Add acknowledgements for Filippo Valsorda and Zaki Manian.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.11}
 
 \begin{itemize}
@@ -3742,6 +3838,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
           follow \cite{BIP-34}.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.10}
 
 \begin{itemize}
@@ -3751,6 +3848,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Clarify the discussion of proof size in ``Differences from the \Zerocash paper''.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.9}
 
 \begin{itemize}
@@ -3758,6 +3856,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Change \quotedterm{protected} terminology to \quotedterm{shielded}.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.8}
 
 \begin{itemize}
@@ -3774,6 +3873,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
           \type{uint32\_t}.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.7}
 
 \begin{itemize}
@@ -3781,6 +3881,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
           response to an issue raised by the NCC audit.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.6}
 
 \begin{itemize}
@@ -3798,6 +3899,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
           Jay Graber, and Jack Gavigan.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.5}
 
 \begin{itemize}
@@ -3805,6 +3907,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Add some clarifications based on Eli Ben-Sasson's review.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.4}
 
 \begin{itemize}
@@ -3814,6 +3917,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
           ``$\typeexp{T}{\ell}$'' for sequence types) to avoid ambiguity.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.3}
 
 \begin{itemize}
@@ -3824,6 +3928,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
           and for the NCC Group and Coinspect security audits.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.2}
 
 \begin{itemize}
@@ -3832,6 +3937,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Correct the security requirement for $\EquihashGen{}$.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1.1}
 
 \begin{itemize}
@@ -3841,6 +3947,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
           than as a distribution of parameters.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-beta-1}
 
 \begin{itemize}
@@ -3882,18 +3989,21 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Terminology changes.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-alpha-3.1}
 
 \begin{itemize}
     \item Change main font to Quattrocento.
 \end{itemize}
 
+\introlist
 \subparagraph{2016.0-alpha-3}
 
 \begin{itemize}
     \item Change version numbering convention (no other changes).
 \end{itemize}
 
+\introlist
 \subparagraph{2.0-alpha-3}
 
 \begin{itemize}
@@ -3902,6 +4012,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Add change history.
 \end{itemize}
 
+\introlist
 \subparagraph{2.0-alpha-2}
 
 \begin{itemize}
@@ -3916,6 +4027,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Changes to terminology around keys.
 \end{itemize}
 
+\introlist
 \subparagraph{2.0-alpha-1}
 
 \begin{itemize}