making further ZIP editor suggested changes, and updating the html fi…

…les to match
QED-it · Aug 14, 2023 · f070692 · f070692
1 parent 7fcd525
commit f070692
Show file tree

Hide file tree

Showing 2 changed files with 5 additions and 5 deletions.
diff --git a/zip-0226.html b/zip-0226.html
@@ -211,11 +211,11 @@
                         <span class="math">\(n\)</span>
                      Actions in a transfer. Out of these
                         <span class="math">\(n\)</span>
-                     Actions, we further distinguish (for the sake of verbosity and clarity) between Actions related to ZEC and Actions related to Custom Assets. We assume
+                     Actions, we further distinguish (for the sake of clarity) between Actions related to ZEC and Actions related to Custom Assets. We assume
                         <span class="math">\(m\)</span>
                      Actions related to ZEC and
                         <span class="math">\(n-m\)</span>
-                     actions related to Custom Assets, where
+                     Actions related to Custom Assets, where
                         <span class="math">\(m \in [0,n]\)</span>
                     . Furthermore, we assume for simplicity that given a tuple of
                         <span class="math">\(n\)</span>
@@ -241,9 +241,9 @@
                      (resp.
                         <span class="math">\(\sum_{i=1}^{m}\)</span>
                     ) returns the identity element of the group.</p>
-                    <p>So, the main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded, so all Custom Assets are contained within the shielded pool. This means that the net balance of the input and output values is zero, with only one Asset of value balance published, that of ZEC,
+                    <p>Thus, the main reason why no changes to the Orchard process are needed is that no Custom Assets can be unshielded within a regular transaction (as opposed to a <em>burn</em>, covered below in the <a href="#burn-mechanism">burn mechanism</a>). All Custom Assets are contained within the shielded pool. This means that the net balance of the input and output values is zero, with only one value balance published, which corresponds to the ZEC value balance
                         <span class="math">\(\mathsf{v^{balanceOrchard}}\)</span>
-                    . No net amount of any other Asset will be revealed, and the number of Assets in the transaction is also hidden. The only exception to this is in the case that an Asset is <em>burnt</em>, as we will see below in the <a href="#burn-mechanism">burn mechanism</a>.</p>
+                    . No net amount of any other Asset will be revealed, and the number of Assets in the transaction is also hidden.</p>
                     <p>As in the Orchard protocol, the binding signature verification key,
                         <span class="math">\(\mathsf{bvk}\)</span>
                     , will only be valid (and hence verify the signature correctly), as long as the committed values sum to zero. In contrast, in this protocol, the committed values only sum to zero <strong>per Asset Base</strong>, as the Pedersen commitments add up homomorphically only with respect to the same value base point.</p>

diff --git a/zip-0226.rst b/zip-0226.rst
@@ -177,7 +177,7 @@ After computing :math:`\mathsf{bvk}`, the verifier MUST use it to verify the bin
 Rationale for Value Balance Verification
 ````````````````````````````````````````
 
-We assume :math:`n` Actions in a transfer. Out of these :math:`n` Actions, we further distinguish (for the sake of verbosity and clarity) between Actions related to ZEC and Actions related to Custom Assets. We assume :math:`m` Actions related to ZEC and :math:`n-m` Actions related to Custom Assets, where :math:`m \in [0,n]`. Furthermore, we assume for simplicity that given a tuple of :math:`n` Actions in a transfer, the :math:`m` Actions related to ZEC are first (in practice Actions could be in whatever order).
+We assume :math:`n` Actions in a transfer. Out of these :math:`n` Actions, we further distinguish (for the sake of clarity) between Actions related to ZEC and Actions related to Custom Assets. We assume :math:`m` Actions related to ZEC and :math:`n-m` Actions related to Custom Assets, where :math:`m \in [0,n]`. Furthermore, we assume for simplicity that given a tuple of :math:`n` Actions in a transfer, the :math:`m` Actions related to ZEC are first (in practice Actions could be in whatever order).
 
 The value balance verification is equivalent to: