assetid review

zip-0226.html

@@ -324,7 +324,7 @@
                 </li>
             </ul>
             <p><strong>Enabling Backwards Compatibility with ZEC Notes:</strong> the following constraints must be added to enable backwards compatibility with Orchard ZEC notes.</p>
-            <p>The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.</p>
+            <p>The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them. However, new notes will always be ZSA notes with an Asset Base.</p>
             <p>The input note in the old note commitment integrity check must either include an Asset Base (ZSA note) or not (ZEC-Orchard note). If the note is an old note, from before the upgrade, the commitment is computed in the original Orchard fashion. If the note is a new ZSA note, there are two cases:</p>
             <ul>
                 <li>

zip-0226.rst

@@ -234,6 +234,7 @@ the input and output note are of the same :math:`\mathsf{AssetId}`:
 **Enabling Backwards Compatibility with ZEC Notes:** the following constraints must be added to enable backwards compatibility with Orchard ZEC notes.
 
 The old note commitment is computed using a “rolling-aggregate” Sinsemilla commitment. This means that the commitment is computed by adding new chunks or windows to the accumulated value. This method will be used in order to maintain a single commitment instance for the old note commitment, that will be used both for Orchard ZEC notes and for ZSA notes. The original Orchard ZEC notes will be conserved and not actually be converted into ZSA notes, as we will always need to compute them.
+However, new notes will always be ZSA notes with an Asset Base.
 
 The input note in the old note commitment integrity check must either include an Asset Base (ZSA note) or not (ZEC-Orchard note). If the note is an old note, from before the upgrade, the commitment is computed in the original Orchard fashion. If the note is a new ZSA note, there are two cases:
 

zip-0227.rst

@@ -130,27 +130,36 @@ The derivation of these keys are shown in the following diagram:
 Asset Identifier
 ----------------
 
-For every new Asset, there must be a new and unique Asset Identifier. We define this to be a globally unique pair :math:`(\mathsf{ik}, \mathsf{asset\_desc})`, where :math:`\mathsf{ik}` is the issuance key and :math:`\mathsf{asset\_desc}` is a byte string.
+Every asset must have a unique Asset Identifier. We define this to be a globally unique pair:
+:math:`(\mathsf{ik}, \mathsf{asset\_desc})`, where: :math:`\mathsf{ik}` is the issuance public key and :math:`\mathsf{asset\_desc}` is a UTF-8 byte string.
 
-A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-based ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, :math:`\mathsf{AssetDigest}`, which is simply is a :math:`\mathsf{BLAKE2b-256}` hash of the Asset Identifier.
-From the Asset Digest, we derive a specific Asset Base within each such shielded protocol (for example :math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}` for the Orchard-based ZSA protocol), using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.
+A given Asset Identifier is used across all Zcash protocols that support ZSAs.
+For this Asset Identifier, we derive an Asset Digest, :math:`\mathsf{AssetDigest}`, which is a :math:`\mathsf{BLAKE2b-256}` hash of the Asset Identifier.
+Then, a specific Asset Base is derived from the Asset Digest within each shielded protocol, using the applicable hash-to-curve algorithm.
+This Asset Base is included in shielded notes.
+
+For the Orchard-based ZSA protocol, we denote this by 
+:math:`\mathsf{AssetBase}^{\mathsf{Orchard}}_{\mathsf{AssetId}}`.
 
 Let 
 
 - :math:`\mathsf{asset\_desc}` be the asset description, a UTF-8 encoded string of up to 512 bytes, which includes any information pertaining to the issuance.
 - :math:`\mathsf{ik}` be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.
 
-Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{AssetId}))`,
+Define :math:`\mathsf{AssetDigest_{\mathsf{AssetId}}} := \mathsf{BLAKE2b\text{-}256}(\text{"ZZSA-AssetDigest"}, \mathsf{EncodeAssetId}(\mathsf{AssetId}))`,
+
 where
 
-- :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}\!`.
+- :math:`\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}) := \mathsf{repr}_{\mathbb{P}}(\mathsf{ik}) || \mathsf{asset\_desc}`.
 
 Define :math:`\mathsf{AssetBase^{Protocol}_{\mathsf{AssetId}}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest}_{\mathsf{AssetId}})`,
 where
 
 In the case of Orchard, we define :math:`\mathsf{ZSAValueBase^{Orchard}}(\mathsf{asset\_id}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{asset\_id})`
 where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in [#protocol-concretegrouphashpallasandvesta]_.
 
+Note that for the native ZEC Asset in Orchard, we define :math:`\mathsf{AssetBase^{Orchard}_{\mathsf{ZEC}}} := \mathcal{V}^{\mathsf{Orchard}}`. 
+
 The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:
 
 .. figure:: zip-0227-asset-identifier-relation.png
@@ -216,10 +225,10 @@ The issuer program performs the following operations
 
 For all actions `IssueAction`:
 
-- encode :math:`\mathsf{asset\_desc}` as 512 byte-string.
+- encode :math:`\mathsf{asset\_desc}` as a UTF-8 byte string of size up to 512.
 - compute :math:`\mathsf{AssetDigest} := \mathsf{BLAKE2b\text{-}256}(\mathsf{EncodeAssetId}(\mathsf{ik}, \mathsf{asset\_desc}))`
 - compute :math:`\mathsf{AssetBase^{Protocol}} := \mathsf{ZSAValueBase^{Protocol}}(\mathsf{AssetDigest})`
-- set the ``finalize`` boolean as desired (if more more issuance actions are to be created for this Asset Identifier, set ``finalize = 0``, otherwise set ``finalize = 1``)
+- set the ``finalize`` bit (if more issuance actions are to be created for this Asset Identifier, set ``finalize = 0``, otherwise set ``finalize = 1``)
 - For each recipient :math:`i`:
 
     - generate a ZSA output note that includes the Asset Base. For an Orchard-based ZSA note this is :math:`\mathsf{note}_i = (\mathsf{d}_i, \mathsf{pk}_{\mathsf{d},i}, \mathsf{v}_i, \rho_i, \psi_i, \mathsf{AssetBase^{Orchard}}, \mathsf{rcm}_i)\!`.
@@ -230,12 +239,12 @@ For the `IssueBundle`:
 
 - encode the `vIssueActions` vector
 - encode the :math:`\mathsf{ik}` as 32 byte-string
-- sign the `SIGHASH` of the transaction with the issuance authorizing key, :math:`\mathsf{isk}`, using the RedPallas signature scheme. The signature is then added to the issuance bundle.
+- sign the `SIGHASH` of the transaction with the issuance authorizing key, :math:`\mathsf{isk}`, using the RedPallas signature scheme. The signature is then added to the issuance bundle. (see Deirdre comment about serialization - should be done similarly to orchard Spend Sig)
 
 
 NOTE that the commitment is not included in the `IssuanceAction` itself. As explained below, it is later computed by the validators and added to the `NoteCommitmentTree`.
 
-Concrete Applications
+Concrete Applications (lets move this section into Rationale, this header should be a sub header inside Rationale, remove duplicate text in the Unified section)
 ---------------------
 
 **Bridging Assets**
@@ -266,8 +275,8 @@ For the IssueBundle:
 For each `IssueAction` in `IssueBundle`:
 
 - check that :math:`\mathsf{asset\_desc}` is a string with `0 < byte size <= 512`.
-- retrieve :math:`\mathsf{AssetId}` from the first note in the sequence and check that :math:`\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}` is properly derived.
-- check that the :math:`\mathsf{AssetId}` does not exist in the ``previously_finalized`` set in the global state.
+- retrieve :math:`\mathsf{AssetId}` from the first note in the sequence and check that :math:`\mathsf{AssetId = GroupHash^{\mathbb{P}}(ik || asset\_desc)}` is properly derived.(use same Terminology as previously)
+- check that the :math:`\mathsf{AssetId}` does not exist in the ``previously_finalized`` set in the global state. 
 - check that every note in the `IssueAction` contains the same :math:`\mathsf{AssetId}` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetId})`.
 
 If all of the above checks pass, do the following: