ZIP 316: Cosmetics.

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

zip-0316.rst

@@ -327,13 +327,13 @@ of the consituent Receivers:
   above Priority List;
 
 * :math:`\mathtt{length} : \mathtt{compactSize}` — the length in bytes of
-  :math:`\mathtt{addr}`;
+  :math:`\mathtt{addr};`
 
 * :math:`\mathtt{addr} : \mathtt{byte[length]}` — the Receiver Encoding.
 
 A Receiver Encoding is the raw encoding of a Shielded Payment Address,
-or the :math:`160`-bit script hash of a P2SH address [#P2SH]_, or the
-:math:`160`-bit validating key hash of a P2PKH address [#P2PKH]_.
+or the :math:`160\!`-bit script hash of a P2SH address [#P2SH]_, or the
+:math:`160\!`-bit validating key hash of a P2PKH address [#P2PKH]_.
 
 Let ``padding`` be the Human-Readable Part of the Unified Address in
 US-ASCII, padded to 16 bytes with zero bytes. We append ``padding`` to
@@ -440,15 +440,16 @@ Requirements for both Unified Addresses and Unified Viewing Keys
 Adding new types
 ----------------
 
-It is intended that new Receiver Types and Viewing Key Types SHOULD be
-introduced either by a modification to this ZIP or by a new ZIP, in accordance
-with the ZIP Process [#zip-0000]_.
+It is intended that new Receiver Types and Viewing Key Types SHOULD
+be introduced either by a modification to this ZIP or by a new ZIP,
+in accordance with the ZIP Process [#zip-0000]_.
 
-Experimental types MAY be added using the reserved Typecodes 0xFFFA to 0xFFFF
-inclusive. This provides for six simultaneous experiments, which can be
-referred to as experiments A to F. This should be sufficient because
-experiments are expected to be reasonably short-term, and should otherwise
-be either standardized in a ZIP (and allocated a Typecode outside this
+Experimental types MAY be added using the reserved Typecodes
+:math:`\mathtt{0xFFFA}` to :math:`\mathtt{0xFFFF}` inclusive. This
+provides for six simultaneous experiments, which can be referred to
+as experiments A to F. This should be sufficient because experiments
+are expected to be reasonably short-term, and should otherwise be
+either standardized in a ZIP (and allocated a Typecode outside this
 reserved range) or discontinued.
 
 
@@ -489,8 +490,8 @@ properties of checksums, etc.
 
 The generic attack puts an upper bound on the achievable security: if it
 takes work :math:`w` to produce and verify a UA, and the size of the character
-set is :math:`c`, then the generic attack costs :math:`\sim \frac{w \cdot
-c^{n+m}}{q}`.
+set is :math:`c,` then the generic attack costs :math:`\sim \frac{w \cdot
+c^{n+m}}{q}.`
 
 There is also a generic brute force attack against nonmalleability. The
 adversary modifies the target Address slightly and computes the corresponding
@@ -505,9 +506,9 @@ Solution
 We use an unkeyed 4-round Feistel construction to approximate a random
 permutation. (As explained below, 3 rounds would not be sufficient.)
 
-Let :math:`H_i` be a hash personalized by :math:`i`, with maximum output
+Let :math:`H_i` be a hash personalized by :math:`i,` with maximum output
 length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with
-extendable output length) based on :math:`H`, personalized by :math:`i`.
+extendable output length) based on :math:`H,` personalized by :math:`i.`
 
 Given input :math:`M` of length :math:`\ell_M` bytes such that
 :math:`48 \leq \ell_M \leq 4194368,` define :math:`\mathsf{F4Jumble}(M)`
@@ -520,10 +521,10 @@ by:
 * let :math:`y = a \oplus H_0(x)`
 * let :math:`d = x \oplus G_1(y)`
 * let :math:`c = y \oplus H_1(d)`
-* return :math:`c \,||\, d`.
+* return :math:`c \,||\, d.`
 
 The inverse function :math:`\mathsf{F4Jumble}^{-1}` is obtained in the usual
-way for a Feistel construction, by observing that :math:`r = p \oplus q` implies :math:`p = r \oplus q`.
+way for a Feistel construction, by observing that :math:`r = p \oplus q` implies :math:`p = r \oplus q.`
 
 The first argument to BLAKE2b below is the personalization.
 
@@ -579,31 +580,31 @@ A 3-round unkeyed Feistel, as shown, is not sufficient:
     Diagram of 3-round unkeyed Feistel construction
 
 Suppose that an adversary has a target input/output pair
-:math:`(a \,||\, b, c \,||\, d)`, and that the input to :math:`H_0` is
-:math:`x`. By fixing :math:`x`, we can obtain another pair
+:math:`(a \,||\, b, c \,||\, d),` and that the input to :math:`H_0` is
+:math:`x.` By fixing :math:`x,` we can obtain another pair
 :math:`((a \oplus t) \,||\, b', (c \oplus t) \,||\, d')` such that
 :math:`a \oplus t` is close to :math:`a` and :math:`c \oplus t` is close
-to :math:`c`.
-(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d`,
+to :math:`c.`
+(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d,`
 but that isn't necessarily required for a valid attack.)
 
 A 4-round Feistel thwarts this and similar attacks. Defining :math:`x` and
 :math:`y` as the intermediate values in the first diagram above:
 
-* if :math:`(x', y')` are fixed to the same values as :math:`(x, y)`, then
-  :math:`(a', b', c', d') = (a, b, c, d)`;
+* if :math:`(x', y')` are fixed to the same values as :math:`(x, y),` then
+  :math:`(a', b', c', d') = (a, b, c, d);`
 
-* if :math:`x' = x` but :math:`y' \neq y`, then the adversary is able to
-  introduce a controlled :math:`\oplus`-difference
-  :math:`a \oplus a' = y \oplus y'`, but the other three pieces
+* if :math:`x' = x` but :math:`y' \neq y,` then the adversary is able to
+  introduce a controlled :math:`\oplus\!`-difference
+  :math:`a \oplus a' = y \oplus y',` but the other three pieces
   :math:`(b, c, d)` are all randomized, which is sufficient;
 
-* if :math:`y' = y` but :math:`x' \neq x`, then the adversary is able to
-  introduce a controlled :math:`\oplus`-difference
-  :math:`d \oplus d' = x \oplus x'`, but the other three pieces
+* if :math:`y' = y` but :math:`x' \neq x,` then the adversary is able to
+  introduce a controlled :math:`\oplus\!`-difference
+  :math:`d \oplus d' = x \oplus x',` but the other three pieces
   :math:`(a, b, c)` are all randomized, which is sufficient;
 
-* if :math:`x' \neq x` and :math:`y' \neq y`, all four pieces are
+* if :math:`x' \neq x` and :math:`y' \neq y,` all four pieces are
   randomized.
 
 Note that the size of each piece is at least 24 bytes.
@@ -633,23 +634,24 @@ compressions for :math:`192 < \ell_M \leq 256,` for example. The maximum
 cost for which the algorithm is defined would be 196608 BLAKE2b compressions
 at :math:`\ell_M = 4194368` bytes.
 
-A naïve implementation of the :math:`F4Jumble^{-1}` function would require
-roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state. However,
-it is possible to reduce this by streaming the :math:`d` part of the jumbled
-encoding three times from a less memory-constrained device. It is essential
-that the streamed value of :math:`d` is the same on each pass, which can be
-verified using a MAC (with key held only by the Consumer) or
+A naïve implementation of the :math:`\mathsf{F4Jumble}^{-1}` function would
+require roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state.
+However, it is possible to reduce this by streaming the :math:`d` part of
+the jumbled encoding three times from a less memory-constrained device. It
+is essential that the streamed value of :math:`d` is the same on each pass,
+which can be verified using a MAC (with key held only by the Consumer) or
 collision-resistant hash function. After the first pass of :math:`d`, the
-implementation is able to compute :math:`y`; after the second pass it is
-able to compute :math:`a`; and the third allows it to compute and
+implementation is able to compute :math:`y;` after the second pass it is
+able to compute :math:`a;` and the third allows it to compute and
 incrementally parse :math:`b.` The maximum memory usage during this process
 would be 128 bytes (for the cached :math:`c` or :math:`y`), plus two BLAKE2b
 hash states.
 
-Since this streaming implementation of :math:`F4Jumble^{-1}` is quite
-complicated, we do not require all Consumers to support it. If a Consumer
-implementation cannot support UAs / UVKs up to the maximum length, it MUST
-nevertheless support UAs / UVKs with :math:`\ell_M` of at least 256 bytes.
+Since this streaming implementation of :math:`\mathsf{F4Jumble}^{-1}` is
+quite complicated, we do not require all Consumers to support it. If a
+Consumer implementation cannot support UAs / UVKs up to the maximum length,
+it MUST nevertheless support UAs / UVKs with :math:`\ell_M` of at least
+:math:`256` bytes.
 
 
 Dependencies