Suggestions from ZIP review: clarifications and typographical edits.

Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com>

zip-0226.rst

@@ -177,15 +177,15 @@ 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:
 
 .. math:: \mathsf{bvk} = (\sum_{i=1}^{m} \mathsf{cv^{net}}_{i}) + (\sum_{j=m+1}^{n} \mathsf{cv^{net}}_j) - \mathsf{ValueCommit_0^{OrchardZSA}(v^{balanceOrchard}, \mathcal{V}^{Orchard})}
 
 This equation contains the balance check of the Orchard protocol [#protocol-binding]_. With ZSA, transfer Actions for Custom Assets MUST also be balanced across asset bases. As such, for a correctly constructed transaction, we MUST get :math:`\mathsf{(\sum_{j=m+1}^{n} v_j^{net}) = 0}`, and thus be left with :math:`\mathsf{\sum_{j=m+1}^{n} rcv_{j}^{net}}\mathcal{R}^{\mathsf{Orchard}}` in the expression. If :math:`m=n` (resp. :math:`m=0`), i.e. all Actions relate to ZEC (resp. Custom Assets), then :math:`m+1>n` (resp. :math:`1>m`), and thus the sum :math:`\sum_{j=m+1}^{n}` (resp. :math:`\sum_{i=1}^{m}`) returns the identity element of the group.
 
-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, :math:`\mathsf{v^{balanceOrchard}}`. 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 *burnt*, as we will see below in the `burn mechanism`_.
+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 *burn*, covered below in the `burn mechanism`_). 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 :math:`\mathsf{v^{balanceOrchard}}`. No net amount of any other Asset will be revealed, and the number of Assets in the transaction is also hidden.
 
 As in the Orchard protocol, the binding signature verification key, :math:`\mathsf{bvk}`, 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 **per Asset Base**, as the Pedersen commitments add up homomorphically only with respect to the same value base point.