Use \pnote macro.

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

protocol/protocol.tex

@@ -796,7 +796,7 @@ paying parties. \emph{However} if two parties collude to compare a
 case that a payee wishes to prevent this they should create a distinct
 \paymentAddress for each payer.
 
-\subparagraph{Note:}
+\pnote{
 It is conventional in cryptography to refer to the key used to encrypt
 a message in an asymmetric encryption scheme as the ``public key".
 However, the public key used as the \transmissionKey component
@@ -807,7 +807,7 @@ This also helps to reduce reliance of the overall protocol on the security
 of the cryptosystem used for \note encryption (see \crossref{inband}), since
 an adversary would have to know $\TransmitPublic$ in order to exploit a
 hypothetical weakness in that cryptosystem.
-
+}
 
 \nsubsection{\Notes}
 
@@ -1082,8 +1082,9 @@ that derives the $\KA$ public key corresponding to a given $\KA$ private key.
 Let $\KAAgree \typecolon \KAPrivate \times \KAPublic \rightarrow \KASharedSecret$
 be the agreement function.
 
-\subparagraph{Note:}
+\pnote{
 The range of $\KADerivePublic$ may be a strict subset of $\KAPublic$.
+}
 
 \begin{securityrequirements}
   \item $\KAFormatPrivate$ must preserve sufficient entropy from its input to be used
@@ -1137,12 +1138,13 @@ If the adversary's advantage is negligible, then the asymmetric encryption schem
 constructed from $\KA$, $\KDF$ and $\Sym$ in \crossref{inband} will be key-private
 as defined in \cite{BBDP2001}.
 
-\subparagraph{Note:}
+\pnote{
 The given definition only requires ciphertexts to be indistinguishable
 between \transmissionKeys that are outputs of $\KADerivePublic$ (which
 includes all keys generated as in \crossref{keycomponents}). If a
 \transmissionKey not in that range is used, it may be distinguishable.
 This is not considered to be a significant security weakness.
+}
 
 
 \nsubsubsection{Signatures} \label{abstractsig}
@@ -1449,12 +1451,13 @@ treated like an \emph{output} value, whereas} $\vpubNew$ is treated like an
 \emph{input} value.
 
 \changed{
-\subparagraph{Note:}
+\pnote{
 Unlike original \Zerocash \cite{BCG+2014}, \Zcash does not have
 a distinction between Mint and Pour operations. The addition of $\vpubOld$ to a
 \joinSplitDescription subsumes the functionality of both Mint and Pour. Also,
 \joinSplitDescriptions are indistinguishable regardless of the number of real input
 \notes.
+}
 
 As stated in \crossref{joinsplitdesc}, either $\vpubOld$ or $\vpubNew$ \MUST be zero.
 No generality is lost because, if a \transaction in which both $\vpubOld$ and
@@ -1768,9 +1771,10 @@ and produces a 256-bit hash. \cite{NIST2015}
 
 \hskip 2em $\MerkleCRH(\mathsf{left}, \mathsf{right}) := \CRHbox{\merklebox}$.
 
-\subparagraph{Note:}
+\pnote{
 $\SHA$ is not the same as the $\FullHashName$ function, which hashes arbitrary-length
 sequences.
+}
 
 \securityrequirement{
 $\SHA$ must be collision-resistant, and it must be infeasible to find a preimage $x$
@@ -1932,7 +1936,7 @@ all instantiated using the $\SHAName$ function:
 \end{securityrequirements}
 
 \changed{
-\subparagraph{Note:}
+\pnote{
 The first four bits --i.e.\ the most significant four bits of the first byte--
 are used to distinguish different uses of $\SHA$, ensuring that the functions
 are independent. In addition to the inputs shown here, the bits $\mathtt{1011}$
@@ -1943,6 +1947,7 @@ extensions that either increase $\NOld$ and/or $\NNew$ to 3, or that add an
 additional bit to $\AuthPrivate$ to encode a new key type, or that require an
 additional PRF.)
 }
+}
 
 \nsubsubsection{\SymmetricEncryption} \label{concretesym}
 
@@ -2082,10 +2087,9 @@ The resulting hash $\cm = \NoteCommit(\NoteTuple{})$. \todo{separate concrete}
 \end{bytefield}
 \end{lrbox}
 
-\changed{
 \hskip 1em $\cm := \FullHashbox{\cmbox}$
 
-\subparagraph{Note:}
+\pnote{
 The leading byte of the $\FullHash$ input is $\hexint{B0}$.
 }
 
@@ -2236,12 +2240,14 @@ The raw encoding of a \spendingKey consists of, in order:
 \changed{
 The zero padding occupies the most significant 4 bits of the third byte.
 
-\subparagraph{Note:} If an implementation represents $\AuthPrivate$
+\pnote{
+If an implementation represents $\AuthPrivate$
 internally as a sequence of 32 bytes with the 4 bits of zero padding
 intact, it will be in the correct form for use as an input to
 $\PRFaddr{}$, $\PRFnf{}$, and $\PRFpk{}$ without need for bit-shifting.
 Future key representations may make use of these padding bits.
 }
+}
 
 
 \nsubsection{\ZeroKnowledgeProvingSystem} \label{proofs}
@@ -2296,13 +2302,14 @@ $(\Proof_A  \typecolon \GroupG{1},\;
   \Proof_H  \typecolon \GroupG{1})$.
 It is computed using the parameters above as described in \cite[Appendix B]{BCTV2015}.
 
-\subparagraph{Note:}
+\pnote{
 Many details of the \provingSystem are beyond the scope of this protocol
 document. For example, the \arithmeticCircuit verifying the \joinSplitStatement,
 or its expression as a \rankOneConstraintSystem, are not specified here.
 In practice it will be necessary to use the specific proving and verification keys
 generated for the \Zcash production \blockchain, and a \provingSystem implementation
 that is interoperable with the \Zcash fork of \libsnark, to ensure compatibility.
+}
 
 \nsubsubsection{Encoding of Points} \label{pointencoding}
 
@@ -2479,11 +2486,12 @@ The changes relative to \Bitcoin version 1 transactions as described in \cite{Bi
 Software that creates \transactions{} \SHOULD use version 1 for \transactions with no
 \joinSplitDescriptions.
 
-\subparagraph{Note:}
+\pnote{
 A \transactionVersionNumber of 2 does not have the same meaning as in \Bitcoin, where
 it is associated with support for \texttt{OP\_CHECKSEQUENCEVERIFY} as specified in \cite{BIP-68}.
 \Zcash was forked from \Bitcoin v0.11.2 and does not support BIP 68, or the related BIPs
 9, 112 and 113.
+}
 
 \nsubsection{Encoding of \JoinSplitDescriptions} \label{joinsplitencoding}
 
@@ -2588,9 +2596,10 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-
   \item The type of the $\nNonce$ field has changed from \type{uint32\_t} to \type{char[32]}.
 \end{itemize}
 
-\subparagraph{Note:}
+\pnote{
 There is no relation between the values of the $\versionField$ field of a \transaction, and
 the $\nVersion$ field of a \blockHeader.
+}
 
 \nsubsection{Proof of Work}
 
@@ -2663,9 +2672,10 @@ For all $r \in \range{1}{k\!-\!1}$, for all $w \in \range{0}{2^{k-r}\!-\!1}$:
   \item $\Xi_r(w 2^r + 1, w 2^r + 2^{r-1}) < \Xi_r(w 2^r + 2^{r-1} + 1, w 2^r + 2^r)$.
 \end{itemize}
 
-\subparagraph{Note:}
+\pnote{
 This does not include a difficulty condition, because here we are defining validity
 of an Equihash solution independent of difficulty.
+}
 
 An Equihash solution with $n = 200$ and $k = 9$ is encoded in the $\nSolution$
 field of a \blockHeader as follows:
@@ -2922,7 +2932,7 @@ that this reduces the number of $\SHA$ evaluations needed to compute
 each \noteCommitment from three to two, saving a total of four $\SHA$
 evaluations in the \joinSplitStatement.
 
-\subparagraph{Note:}
+\pnote{
 \Zcash \noteCommitments are not statistically hiding,
 so \Zcash does not support the ``everlasting anonymity'' property
 described in \cite[section 8.1]{BCG+2014},
@@ -2930,6 +2940,7 @@ even when used as described in that section. While it is possible to
 define a statistically hiding, computationally binding commitment scheme
 for this use at a 128-bit security level, the overhead of doing so
 within the \joinSplitStatement was not considered to justify the benefits.
+}
 
 \nsubsection{Changes to PRF inputs and truncation} \label{truncation}