Improved description of the burn mechanism, and rationale for asset d…

…escription string size (#61)

This rewrites the burn mechanism description in ZIP 226 in order to
remove some ambiguously defined terms, and improve the clarity of the
specification.

It also adds the rationale for the choice of 512 bytes for the maximum
length of the asset description string in ZIP 227, which resolves zcash#843
(along with the additions in the already merged #59)

rendered/zip-0226.html

@@ -195,23 +195,23 @@
                 </section>
             </section>
             <section id="burn-mechanism"><h3><span class="section-heading">Burn Mechanism</span><span class="section-anchor"> <a rel="bookmark" href="#burn-mechanism"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
-                <p>The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Asset Identifier to be "destroyed". The burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given Custom Asset in circulation at the consensus level. It is enforced at the consensus level, by using an extension of the value balance mechanism used for ZEC Assets. Burning makes it globally provable that a given amount of an Asset has been destroyed.</p>
-                <p>The sender includes a
-                    <span class="math">\(\mathsf{v_{AssetId}}\)</span>
-                 variable for every Asset Identifier that is being burnt, which represents the amount of that Asset being burnt. As described in the <a href="#orchard-zsa-transaction-structure">Orchard-ZSA Transaction Structure</a>, this is separate from the regular
-                    <span class="math">\(\mathsf{valueBalance^{Orchard}}\)</span>
-                 that is the default transparent value for the ZEC Asset, and represents either the transaction fee, or the amount of ZEC changing pools (e.g. to Sapling or Transparent).</p>
-                <p>For every Custom Asset that is burnt, we add to the
+                <p>The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Custom Asset to be "destroyed" by the holder. The burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given Custom Asset in circulation. It is enforced at the consensus level, by using an extension of the value balance mechanism used for ZEC Assets. Burning makes it globally provable that a given amount of a Custom Asset has been destroyed. Note that the OrchardZSA Protocol does not allow for the burning of ZEC (or TAZ).</p>
+                <p>In the <a href="#orchard-zsa-transaction-structure">Orchard-ZSA Transaction Structure</a>, there is now an
                     <span class="math">\(\mathsf{assetBurn}\)</span>
-                 set the tuple
-                    <span class="math">\((\mathsf{AssetBase_{AssetId}}, \mathsf{v_{AssetId}})\)</span>
-                 such that the validator of the transaction can compute the value commitment with the corresponding value base point of that Asset. This ensures that the values are all balanced out with respect to the Asset Identifiers in the transfer.</p>
-                <div class="math">\(\mathsf{assetBurn} := \{ (\mathsf{AssetBase}_{\mathsf{AssetId}} : \mathbb{P}^*, \mathsf{v_{AssetId}} : \{1 .. 2^{\ell_{\mathsf{value}}} - 1\}) \,|\, \mathsf{AssetId} \in \mathsf{AssetIdsToBurn} \}\)</div>
-                <p>We denote by
+                 set. For every Custom Asset (represented by its
+                    <span class="math">\(\mathsf{AssetBase}\!\)</span>
+                ) that is burnt in the transaction, the sender adds to
+                    <span class="math">\(\mathsf{assetBurn}\)</span>
+                 the tuple
+                    <span class="math">\((\mathsf{AssetBase}, \mathsf{v})\)</span>
+                , where
+                    <span class="math">\(\mathsf{v}\)</span>
+                 is the amount of the Custom Asset the sender wants to burn. We denote by
                     <span class="math">\(L\)</span>
                  the cardinality of the
                     <span class="math">\(\mathsf{assetBurn}\)</span>
-                 set.</p>
+                 set in a transaction.</p>
+                <p>As described in <a href="#value-balance-verification">Value Balance Verification</a>, this provides the information for the validator of the transaction to compute the value commitment with the corresponding Asset Base. This ensures that the values are all balanced out on a per-Asset basis in the transaction.</p>
                 <section id="additional-consensus-rules"><h4><span class="section-heading">Additional Consensus Rules</span><span class="section-anchor"> <a rel="bookmark" href="#additional-consensus-rules"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
                     <ol type="1">
                         <li>Check that for every

rendered/zip-0227.html

@@ -627,6 +627,9 @@
                         <li>information to be committed by the issuer, though not enforceable by the protocol.</li>
                     </ul>
                 </li>
+                <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

zips/zip-0226.rst

@@ -168,16 +168,18 @@ The use of different value base points for different Assets enables the final ba
 Burn Mechanism
 --------------
 
-The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Asset Identifier to be "destroyed". The burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given Custom Asset in circulation at the consensus level. It is enforced at the consensus level, by using an extension of the value balance mechanism used for ZEC Assets.
-Burning makes it globally provable that a given amount of an Asset has been destroyed.
-
-The sender includes a :math:`\mathsf{v_{AssetId}}` variable for every Asset Identifier that is being burnt, which represents the amount of that Asset being burnt. As described in the `Orchard-ZSA Transaction Structure`_, this is separate from the regular :math:`\mathsf{valueBalance^{Orchard}}` that is the default transparent value for the ZEC Asset, and represents either the transaction fee, or the amount of ZEC changing pools (e.g. to Sapling or Transparent).
-
-For every Custom Asset that is burnt, we add to the :math:`\mathsf{assetBurn}` set the tuple :math:`(\mathsf{AssetBase_{AssetId}}, \mathsf{v_{AssetId}})` such that the validator of the transaction can compute the value commitment with the corresponding value base point of that Asset. This ensures that the values are all balanced out with respect to the Asset Identifiers in the transfer.
-
-.. math:: \mathsf{assetBurn} := \{ (\mathsf{AssetBase}_{\mathsf{AssetId}} : \mathbb{P}^*, \mathsf{v_{AssetId}} : \{1 .. 2^{\ell_{\mathsf{value}}} - 1\}) \,|\, \mathsf{AssetId} \in \mathsf{AssetIdsToBurn} \}
-
-We denote by :math:`L` the cardinality of the :math:`\mathsf{assetBurn}` set.
+The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Custom Asset to be "destroyed" by the holder. 
+The burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given Custom Asset in circulation. 
+It is enforced at the consensus level, by using an extension of the value balance mechanism used for ZEC Assets.
+Burning makes it globally provable that a given amount of a Custom Asset has been destroyed.
+Note that the OrchardZSA Protocol does not allow for the burning of ZEC (or TAZ).
+
+In the `Orchard-ZSA Transaction Structure`_, there is now an :math:`\mathsf{assetBurn}` set. 
+For every Custom Asset (represented by its :math:`\mathsf{AssetBase}\!`) that is burnt in the transaction, the sender adds to :math:`\mathsf{assetBurn}` the tuple :math:`(\mathsf{AssetBase}, \mathsf{v})`, where :math:`\mathsf{v}` is the amount of the Custom Asset the sender wants to burn. 
+We denote by :math:`L` the cardinality of the :math:`\mathsf{assetBurn}` set in a transaction.
+
+As described in `Value Balance Verification`_, this provides the information for the validator of the transaction to compute the value commitment with the corresponding Asset Base. 
+This ensures that the values are all balanced out on a per-Asset basis in the transaction.
 
 Additional Consensus Rules
 ``````````````````````````

zips/zip-0227.rst

@@ -374,6 +374,7 @@ The following is a list of rationale for different decisions made in the proposa
     - bridging information for Wrapped Assets (chain of origin, issuer name, etc)
     - 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.