[ZSA] Applying suggestions from ZIP Review

rendered/zip-0227.html

@@ -624,7 +624,7 @@
                     <span class="math">\(\mathsf{issued\_assets(AssetBase).final}\)</span>
                  to
                     <span class="math">\(1\)</span>
-                 in the global state immediately after the block in which this transaction occurs.</li>
+                 in the global state.</li>
                 <li>(Replay Protection) If issue bundle is present, the fees MUST be greater than zero.</li>
             </ul>
         </section>
@@ -646,11 +646,6 @@
                 <li>We limit the size of the
                     <span class="math">\(\mathsf{asset\_desc}\)</span>
                  string to 512 bytes as it is a reasonable size to store metadata about the Asset, for example in JSON format.</li>
-                <li>We require a check whether the
-                    <span class="math">\(\mathsf{finalize}\)</span>
-                 flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the
-                    <span class="math">\(\mathsf{issued\_assets}\)</span>
-                 map at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.</li>
                 <li>We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.</li>
             </ul>
             <section id="concrete-applications"><h3><span class="section-heading">Concrete Applications</span><span class="section-anchor"> <a rel="bookmark" href="#concrete-applications"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>

rendered/zip-0230.html

@@ -585,7 +585,15 @@
                             <td><code>43</code></td>
                             <td><code>recipient</code></td>
                             <td><code>byte[43]</code></td>
-                            <td>The raw encoding of an Orchard Raw Payment Address, as per protocol §5.6.4.2 ‘Orchard Raw Payment Addresses’.</td>
+                            <td>The encoding of a recipient's diversified payment address, as
+                                <span class="math">\(\mathsf{LEBS2OSP}_{88}(\mathsf{d})\|
+\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{P}}
+(\mathsf{pk}_\mathsf{d}))\!\)</span>
+                            , where
+                                <span class="math">\(\mathsf{d}\)</span>
+                             is the diversifier and
+                                <span class="math">\(\mathsf{pk_d}\)</span>
+                             is the diversified transmission key. <strong>Non Normative Note</strong>: This is the same as the encoding of an Orchard Raw Payment Address, as defined in the protocol specification §5.6.4.2 ‘Orchard Raw Payment Addresses’.</td>
                         </tr>
                         <tr>
                             <td><code>8</code></td>

zips/zip-0227.rst

@@ -362,7 +362,7 @@ If all of the above checks pass, do the following:
   - Add :math:`\mathsf{cm}` to the Merkle tree of note commitments.
   - Increase the value of :math:`\mathsf{issued\_assets(AssetBase).balance}` by the value of the note, :math:`\mathsf{v}`.
 
-- If :math:`\mathsf{finalize} = 1\!`, set :math:`\mathsf{issued\_assets(AssetBase).final}` to :math:`1` in the global state immediately after the block in which this transaction occurs.
+- If :math:`\mathsf{finalize} = 1\!`, set :math:`\mathsf{issued\_assets(AssetBase).final}` to :math:`1` in the global state.
 
 - (Replay Protection) If issue bundle is present, the fees MUST be greater than zero.
 
@@ -382,7 +382,6 @@ The following is a list of rationale for different decisions made in the proposa
     - information to be committed by the issuer, though not enforceable by the protocol.
 
 - We limit the size of the :math:`\mathsf{asset\_desc}` string to 512 bytes as it is a reasonable size to store metadata about the Asset, for example in JSON format.
-- We require a check whether the :math:`\mathsf{finalize}` flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the :math:`\mathsf{issued\_assets}` map at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.
 - We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.
 
 Concrete Applications

zips/zip-0230.rst

@@ -342,8 +342,14 @@ An issuance note, ``IssueNote`` contains the following fields:
 +-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+
 | Bytes                       | Name                     | Data Type                            | Description                                                        |
 +=============================+==========================+======================================+====================================================================+
-|``43``                       |``recipient``             |``byte[43]``                          |The raw encoding of an Orchard Raw Payment Address, as              |
-|                             |                          |                                      |per protocol §5.6.4.2 ‘Orchard Raw Payment Addresses’.              |
+|``43``                       |``recipient``             |``byte[43]``                          |The encoding of a recipient's diversified payment address, as       |
+|                             |                          |                                      |:math:`\mathsf{LEBS2OSP}_{88}(\mathsf{d})\|                         |
+|                             |                          |                                      |\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{P}}                  |
+|                             |                          |                                      |(\mathsf{pk}_\mathsf{d}))\!`, where :math:`\mathsf{d}` is the       |
+|                             |                          |                                      |diversifier and :math:`\mathsf{pk_d}` is the diversified            |
+|                             |                          |                                      |transmission key. **Non Normative Note**: This is the same as the   |
+|                             |                          |                                      |encoding of an Orchard Raw Payment Address, as defined in the       |
+|                             |                          |                                      |protocol specification §5.6.4.2 ‘Orchard Raw Payment Addresses’.    |
 +-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+
 |``8``                        |``value``                 |``uint64``                            |The amount being issued in this note.                               |
 +-----------------------------+--------------------------+--------------------------------------+--------------------------------------------------------------------+