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 - \(\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 - \(\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 +
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 \(\mathsf{assetBurn}\) - set the tuple - \((\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.
-We denote by + set. For every Custom Asset (represented by its + \(\mathsf{AssetBase}\!\) + ) that is burnt in the transaction, the sender adds to + \(\mathsf{assetBurn}\) + the tuple + \((\mathsf{AssetBase}, \mathsf{v})\) + , where + \(\mathsf{v}\) + is the amount of the Custom Asset the sender wants to burn. We denote by \(L\) the cardinality of the \(\mathsf{assetBurn}\) - set.
+ 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
- Check that for every diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 89513e33c..7b82fb909 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -627,6 +627,9 @@
- information to be committed by the issuer, though not enforceable by the protocol. +
- We limit the size of the + \(\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 \(\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 diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst index 34341c0bd..bc59c942f 100644 --- a/zips/zip-0226.rst +++ b/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 `````````````````````````` diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst index 3da87f248..175415391 100644 --- a/zips/zip-0227.rst +++ b/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.