From 792ce671baedadeeecb2369d006f668ed5456bca Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sat, 31 Aug 2024 13:13:56 +0530 Subject: [PATCH 1/4] adding rationale for the 512 byte asset_desc string size --- rendered/zip-0227.html | 3 +++ zips/zip-0227.rst | 1 + 2 files changed, 4 insertions(+) diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 89513e33c..751386149 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. It could even be used to store small programs that could be relevant to use cases.
  • 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-0227.rst b/zips/zip-0227.rst index 3da87f248..d2f28227c 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. It could even be used to store small programs that could be relevant to use cases. - 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. From 07c313377b879e6bcc6697a1d72feb558e05ad0f Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 1 Sep 2024 20:19:38 +0530 Subject: [PATCH 2/4] rewriting the burn mechanism for improved clarity --- rendered/zip-0226.html | 24 ++++++++++++------------ zips/zip-0226.rst | 15 ++++++++------- 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/rendered/zip-0226.html b/rendered/zip-0226.html index 5fdacb6ce..428fbb583 100644 --- a/rendered/zip-0226.html +++ b/rendered/zip-0226.html @@ -196,22 +196,22 @@

    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 +

    In the Orchard-ZSA Transaction Structure, there now is 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.

    -
    \(\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 + 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 we will see 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

    1. Check that for every diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst index 34341c0bd..ec51f2a11 100644 --- a/zips/zip-0226.rst +++ b/zips/zip-0226.rst @@ -168,16 +168,17 @@ 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. +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). +In the `Orchard-ZSA Transaction Structure`_, there now is 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. -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. +As we will see 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 `````````````````````````` From 0955982d1676a67cb66149be3ef40107e6a0570b Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 22 Sep 2024 19:59:40 +0530 Subject: [PATCH 3/4] updates based on review comments --- rendered/zip-0226.html | 6 +++--- rendered/zip-0227.html | 2 +- zips/zip-0226.rst | 8 ++++---- zips/zip-0227.rst | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/rendered/zip-0226.html b/rendered/zip-0226.html index 428fbb583..c745f65fa 100644 --- a/rendered/zip-0226.html +++ b/rendered/zip-0226.html @@ -195,8 +195,8 @@

    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.

    -

    In the Orchard-ZSA Transaction Structure, there now is an +

    The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Asset Identifier 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 an Asset has been destroyed.

    +

    In the Orchard-ZSA Transaction Structure, there is now an \(\mathsf{assetBurn}\) set. For every Custom Asset (represented by its \(\mathsf{AssetBase}\!\) @@ -211,7 +211,7 @@ the cardinality of the \(\mathsf{assetBurn}\) set in a transaction.

    -

    As we will see 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.

    +

    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

    1. Check that for every diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html index 751386149..7b82fb909 100644 --- a/rendered/zip-0227.html +++ b/rendered/zip-0227.html @@ -629,7 +629,7 @@
    2. 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. It could even be used to store small programs that could be relevant to use cases.
      3. + string to 512 bytes as it is a reasonable size to store metadata about the Asset, for example in JSON format.
    3. 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 ec51f2a11..bc0523e09 100644 --- a/zips/zip-0226.rst +++ b/zips/zip-0226.rst @@ -168,16 +168,16 @@ 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. +The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Asset Identifier 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 an Asset has been destroyed. -In the `Orchard-ZSA Transaction Structure`_, there now is an :math:`\mathsf{assetBurn}` set. +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 we will see in `Value Balance Verification`_, this provides the information for the validator of the transaction to compute the value commitment with the corresponding Asset Base. +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 d2f28227c..175415391 100644 --- a/zips/zip-0227.rst +++ b/zips/zip-0227.rst @@ -374,7 +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. It could even be used to store small programs that could be relevant to use cases. +- 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. From c595ab1464f6b7f92adb2263c7c381294597ffd3 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Wed, 25 Sep 2024 14:53:58 +0530 Subject: [PATCH 4/4] adding statement in intro of burn section to preclude burning ZEC --- rendered/zip-0226.html | 2 +- zips/zip-0226.rst | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/rendered/zip-0226.html b/rendered/zip-0226.html index c745f65fa..ff107ee92 100644 --- a/rendered/zip-0226.html +++ b/rendered/zip-0226.html @@ -195,7 +195,7 @@

    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" 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 an Asset has been destroyed.

    +

    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. For every Custom Asset (represented by its diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst index bc0523e09..bc59c942f 100644 --- a/zips/zip-0226.rst +++ b/zips/zip-0226.rst @@ -168,10 +168,11 @@ 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" by the holder. +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 an Asset has been destroyed. +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.