ZIP 216: cosmetics.

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

zip-0216.html

@@ -40,40 +40,40 @@
             -coordinate zero:</p>
             <ul>
                 <li>
-                    <span class="math">\((0, 1)\)</span>
+                    <span class="math">\((0, 1)\!\)</span>
                 , which is the identity;</li>
                 <li>
-                    <span class="math">\((0, -1)\)</span>
+                    <span class="math">\((0, -1)\!\)</span>
                 , which is a point of order two.</li>
             </ul>
             <p>Each of these has a single non-canonical encoding in which the value of the sign bit is
-                <span class="math">\(1\)</span>
+                <span class="math">\(1\!\)</span>
             .</p>
             <p>This creates a consensus issue because (unlike other non-canonical point encodings that are rejected) either of the above encodings can be decoded, and then re-encoded to a <em>different</em> encoding. For example, if a non-canonical encoding appeared in a transaction field, then node implementations that store points internally as abstract curve points, and used those to derive transaction IDs, would derive different IDs than nodes which store transactions as bytes (such as <cite>zcashd</cite>).</p>
             <p>This issue is not known to cause any security vulnerability, beyond the risk of consensus incompatibility. In fact, for some of the fields that would otherwise be affected, the issue does not occur because there are already consensus rules that prohibit small-order points, and this incidentally prohibits non-canonical encodings.</p>
             <p>Adjustments to the protocol specification were made in versions 2020.1.8, 2020.1.9, 2020.1.15, and 2021.1.17 to match the <cite>zcashd</cite> implementation. (The fact that this required 4 specification revisions to get right, conclusively demonstrates the problem.)</p>
         </section>
         <section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
             <p>Let
-                <span class="math">\(\mathsf{abst}_{\mathbb{J}}\)</span>
+                <span class="math">\(\mathsf{abst}_{\mathbb{J}}\!\)</span>
             ,
-                <span class="math">\(\mathsf{repr}_{\mathbb{J}}\)</span>
+                <span class="math">\(\mathsf{repr}_{\mathbb{J}}\!\)</span>
             , and
                 <span class="math">\(q_{\mathbb{J}}\)</span>
              be as defined in <a id="footnote-reference-7" class="footnote_reference" href="#protocol-jubjub">9</a>.</p>
             <p>Define a non-canonical compressed encoding of a Jubjub point to be a sequence of
                 <span class="math">\(256\)</span>
              bits,
-                <span class="math">\(b\)</span>
+                <span class="math">\(b\!\)</span>
             , such that
                 <span class="math">\(\mathsf{abst}_{\mathbb{J}}(b) \neq \bot\)</span>
              and
-                <span class="math">\(\mathsf{repr_{\mathbb{J}}}\big(\mathsf{abst}_{\mathbb{J}}(b)\big) \neq b\)</span>
+                <span class="math">\(\mathsf{repr_{\mathbb{J}}}\big(\mathsf{abst}_{\mathbb{J}}(b)\big) \neq b\!\)</span>
             .</p>
             <p>Non-normative note: There are two such bit sequences,
                 <span class="math">\(\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + 1)\)</span>
              and
-                <span class="math">\(\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + q_{\mathbb{J}} - 1)\)</span>
+                <span class="math">\(\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + q_{\mathbb{J}} - 1)\!\)</span>
             . The Sapling protocol uses little-endian ordering when converting between bit and byte sequences, so the first of these sequences corresponds to a
                 <span class="math">\(\mathtt{0x01}\)</span>
              byte, followed by
@@ -112,7 +112,7 @@
             <blockquote>
                 <ul>
                     <li>
-                        <span class="math">\(\mathsf{pk}\star_{\mathsf{d}}\)</span>
+                        <span class="math">\(\mathsf{pk}\star_{\mathsf{d}}\!\)</span>
                     .</li>
                 </ul>
             </blockquote>
@@ -127,8 +127,8 @@
                         <span class="math">\(\mathtt{cv}\)</span>
                     </li>
                     <li>
-                        <span class="math">\(\mathtt{rk}\)</span>
-                    </li>
+                        <span class="math">\(\mathtt{rk}\!\)</span>
+                    .</li>
                 </ul>
             </blockquote>
             <p>In Sapling Output descriptions <a id="footnote-reference-12" class="footnote_reference" href="#protocol-outputdesc">7</a>:</p>
@@ -138,20 +138,20 @@
                         <span class="math">\(\mathtt{cv}\)</span>
                     </li>
                     <li>
-                        <span class="math">\(\mathtt{ephemeralKey}\)</span>
+                        <span class="math">\(\mathtt{ephemeralKey}\!\)</span>
                     .</li>
                 </ul>
             </blockquote>
             <p>These fields cannot by consensus contain small-order points. All of the points with non-canonical encodings are small-order.</p>
             <p>Implementations MAY choose to reject non-canonical encodings of the above four fields early in decoding of a transaction. This eliminates the risk that parts of the transaction could be re-serialized from their internal representation to a different byte sequence than in the original transaction, e.g. when calculating transaction IDs.</p>
             <p>In addition, Sapling addresses and full viewing keys MUST be considered invalid when imported if they contain non-canonical Jubjub point encodings, or encodings of points that are not in the prime-order subgroup
-                <span class="math">\(\mathbb{J}^{(r)}\)</span>
+                <span class="math">\(\mathbb{J}^{(r)}\!\)</span>
             . These requirements MAY be enforced in advance of NU5 activation.</p>
             <p>In Sapling addresses <a id="footnote-reference-13" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">11</a>:</p>
             <blockquote>
                 <ul>
                     <li>the encoding of
-                        <span class="math">\(\mathsf{pk_d}\)</span>
+                        <span class="math">\(\mathsf{pk_d}\!\)</span>
                     .</li>
                 </ul>
             </blockquote>
@@ -219,11 +219,11 @@
                 <span class="math">\(\mathbb{F}_{r_\mathbb{S}} = \mathbb{F}_{q_\mathbb{J}}\)</span>
             ), and so no issue of encoding canonicity arises.</p>
             <p>Encodings of elliptic curve points on Curve25519, BN-254
-                <span class="math">\(\mathbb{G}_1\)</span>
+                <span class="math">\(\mathbb{G}_1\!\)</span>
             , BN-254
-                <span class="math">\(\mathbb{G}_2\)</span>
+                <span class="math">\(\mathbb{G}_2\!\)</span>
             , BLS12-381
-                <span class="math">\(\mathbb{G}_1\)</span>
+                <span class="math">\(\mathbb{G}_1\!\)</span>
             , and BLS12-381
                 <span class="math">\(\mathbb{G}_2\)</span>
              are not affected.</p>

zip-0216.rst

@@ -59,11 +59,11 @@ This code accepts either sign bit, because ``u_negated == u``.
 
 There are two points on the Jubjub curve with :math:`u\!`-coordinate zero:
 
-- :math:`(0, 1)`, which is the identity;
-- :math:`(0, -1)`, which is a point of order two.
+- :math:`(0, 1)\!`, which is the identity;
+- :math:`(0, -1)\!`, which is a point of order two.
 
 Each of these has a single non-canonical encoding in which the value of the sign bit is
-:math:`1`.
+:math:`1\!`.
 
 This creates a consensus issue because (unlike other non-canonical point encodings that
 are rejected) either of the above encodings can be decoded, and then re-encoded to a
@@ -85,16 +85,16 @@ required 4 specification revisions to get right, conclusively demonstrates the p
 Specification
 =============
 
-Let :math:`\mathsf{abst}_{\mathbb{J}}`, :math:`\mathsf{repr}_{\mathbb{J}}`, and
+Let :math:`\mathsf{abst}_{\mathbb{J}}\!`, :math:`\mathsf{repr}_{\mathbb{J}}\!`, and
 :math:`q_{\mathbb{J}}` be as defined in [#protocol-jubjub]_.
 
 Define a non-canonical compressed encoding of a Jubjub point to be a sequence of
-:math:`256` bits, :math:`b`, such that :math:`\mathsf{abst}_{\mathbb{J}}(b) \neq \bot`
-and :math:`\mathsf{repr_{\mathbb{J}}}\big(\mathsf{abst}_{\mathbb{J}}(b)\big) \neq b`.
+:math:`256` bits, :math:`b\!`, such that :math:`\mathsf{abst}_{\mathbb{J}}(b) \neq \bot`
+and :math:`\mathsf{repr_{\mathbb{J}}}\big(\mathsf{abst}_{\mathbb{J}}(b)\big) \neq b\!`.
 
 Non-normative note: There are two such bit sequences,
 :math:`\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + 1)` and
-:math:`\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + q_{\mathbb{J}} - 1)`.
+:math:`\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + q_{\mathbb{J}} - 1)\!`.
 The Sapling protocol uses little-endian ordering when converting between bit and
 byte sequences, so the first of these sequences corresponds to a :math:`\mathtt{0x01}`
 byte, followed by :math:`30` zero bytes, and then a :math:`\mathtt{0x80}` byte.
@@ -115,7 +115,7 @@ In transactions [#protocol-txnencoding]_:
 In the plaintext obtained by decrypting the :math:`\mathsf{C^{out}}` field of a
 Sapling transmitted note ciphertext [#protocol-decryptovk]_:
 
-  - :math:`\mathsf{pk}\star_{\mathsf{d}}`.
+  - :math:`\mathsf{pk}\star_{\mathsf{d}}\!`.
 
 (This affects decryption of :math:`\mathsf{C^{out}}` in all cases, but is
 consensus-critical only in the case of a shielded coinbase output.
@@ -128,12 +128,12 @@ existing consensus rules.
 In Sapling Spend descriptions:
 
   - :math:`\mathtt{cv}`
-  - :math:`\mathtt{rk}`
+  - :math:`\mathtt{rk}\!`.
 
 In Sapling Output descriptions [#protocol-outputdesc]_:
 
   - :math:`\mathtt{cv}`
-  - :math:`\mathtt{ephemeralKey}`.
+  - :math:`\mathtt{ephemeralKey}\!`.
 
 These fields cannot by consensus contain small-order points. All of the points
 with non-canonical encodings are small-order.
@@ -146,12 +146,12 @@ transaction IDs.
 
 In addition, Sapling addresses and full viewing keys MUST be considered invalid when
 imported if they contain non-canonical Jubjub point encodings, or encodings of points
-that are not in the prime-order subgroup :math:`\mathbb{J}^{(r)}`. These requirements
+that are not in the prime-order subgroup :math:`\mathbb{J}^{(r)}\!`. These requirements
 \MAY be enforced in advance of NU5 activation.
 
 In Sapling addresses [#protocol-saplingpaymentaddrencoding]_:
 
-  - the encoding of :math:`\mathsf{pk_d}`.
+  - the encoding of :math:`\mathsf{pk_d}\!`.
 
 In Sapling full viewing keys [#protocol-saplingfullviewingkeyencoding]_ and extended
 full viewing keys [#zip-0032-extfvk]_:
@@ -226,8 +226,8 @@ coordinates as elements of the correct field
 (:math:`\mathbb{F}_{r_\mathbb{S}} = \mathbb{F}_{q_\mathbb{J}}`),
 and so no issue of encoding canonicity arises.
 
-Encodings of elliptic curve points on Curve25519, BN-254 :math:`\mathbb{G}_1`,
-BN-254 :math:`\mathbb{G}_2`, BLS12-381 :math:`\mathbb{G}_1`, and
+Encodings of elliptic curve points on Curve25519, BN-254 :math:`\mathbb{G}_1\!`,
+BN-254 :math:`\mathbb{G}_2\!`, BLS12-381 :math:`\mathbb{G}_1\!`, and
 BLS12-381 :math:`\mathbb{G}_2` are not affected.
 
 Encodings of elliptic curve points on the Pallas and Vesta curves in the NU5 proposal