Changes to issuance key derivation details (#8)

This covers the changes made to derive the issuance key independently of the Orchard key structure, using the techniques from [ZIP 32](https://zips.z.cash/zip-0032).

zip-0227.rst

@@ -73,13 +73,8 @@ Requirements
 - Every "issuance action" should contain a ``finalize`` boolean that defines whether the specific Custom Asset can have further tokens issued or not.
 
 
-Specification
-=============
-
-As explained, the issuance protocol allows for a single issuance action to be sent to many receivers, by generating as many output notes as distinct recipients. Furthermore, every bundle can contain many issuance actions.
-
-Issuance Keys and Issuance Authorization Signature Scheme
----------------------------------------------------------
+Specification: Issuance Keys and Issuance Authorization Signature Scheme
+========================================================================
 
 The ZSA Protocol adds the following three keys to the key components [#protocol-addressesandkeys]_:
 
@@ -89,19 +84,48 @@ The ZSA Protocol adds the following three keys to the key components [#protocol-
 
 3. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate the issuance transaction. This key is used to validate the issuance of a specific Asset Identifier, and is used by all block chain users (specifically the Asset owners and consensus validators) to associate the Asset in question with the issuer.
 
+The relations between these keys are shown in the following diagram:
+
+.. figure:: zip-0227-key-components-zsa.png
+    :width: 450px
+    :align: center
+    :figclass: align-center
+
+    Diagram of Issuance Key Components for the ZSA Protocol
+
+
 Issuance Authorization Signature Scheme
-```````````````````````````````````````
+---------------------------------------
 
 We define the issuance authorization signature scheme :math:`\mathsf{IssueAuthSig}` similar to :math:`\mathsf{SpendAuthSig}^{\mathsf{Orchard}}`, the Orchard spend authorization signature scheme [#protocol-concretespendauthsig]_. 
 Specifically, we instantiate :math:`\mathsf{IssueAuthSig}` as :math:`\mathsf{RedPallas}` without key re-randomization using generator :math:`\mathcal{P}_{\mathbb{G}} = \mathcal{G}^{\mathsf{Issuance}} := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:ZSA"}, \texttt{"Issuance"})` where :math:`\mathsf{GroupHash}^\mathbb{P}` is defined as in the Zcash protocol specification [#protocol-concretegrouphashpallasandvesta]_.
 
 Issuance Key Derivation
-```````````````````````
+-----------------------
 
 The issuance master key is generated by choosing a bit sequence uniformly at random from :math:`\mathbb{B}^{\mathbb{Y}[32]}`, like the Orchard spending key [#protocol-orchardkeycomponents]_.
-In :math:`\mathsf{zcashd}`, this key is derived in a manner similar to the generation of the Orchard master key in ZIP 32 [#zip-0032-orchard-master]_, as detailed below:
 
-- Details TBD
+Issuance master key derivation for hierarchical deterministic wallets
+`````````````````````````````````````````````````````````````````````
+
+The issuance master key is derived using the Orchard master key derivation procedure defined in ZIP 32 [#zip-0032-orchard-master]_. We reuse the functions defined there in what follows in this section.
+
+Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
+We define the master extended issuance key :math:`m_{\mathsf{Issuance}} := \mathsf{MasterKeyGen}(\texttt{"ZIP32ZSAIssuance"}, S)`.
+
+As in ZIP 32 for Orchard [#zip-0032-orchard-child-key-derivation]_, we only use hardened child key derivation for the issuance master key. 
+We reuse the :math:`\mathsf{CDKsk}` function for Orchard child key derivation from ZIP 32.
+
+We use the notation of ZIP 32 [#zip-0032-orchard-key-path]_ for shielded HD paths, and define the issuance master key path as :math:`m_\mathsf{Issuance} / purpose / coin\_type' / account'`. We fix the path levels as follows:
+
+- :math:`purpose`: a constant set to :math:`227'` (or :math:`\texttt{0x800000e3}`) following the BIP 43 recommendation.
+- :math:`coin\_type`: Defined as in ZIP 32 [#zip-0032-key-path-levels]_.
+- :math:`account`: fixed to index :math:`0`.
+
+Given the *extended issuance master key* :math:`(\mathsf{sk}, \mathsf{c})`, we set the issuance master key to be :math:`\mathsf{sk_{iss}} := \mathsf{sk}`.
+
+Derivation of issuance authorizing key and issuance validating key
+``````````````````````````````````````````````````````````````````
 
 The issuance authorizing key and issuance validating key are derived from the issuance master key in an analogous manner to the derivation of the Orchard spend authorizing key and Orchard spend validating key from the Orchard spending key [#protocol-orchardkeycomponents]_, as described below.
 
@@ -115,18 +139,8 @@ The issuance authorizing key and issuance validating key are derived from the is
 
 This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.
 
-The derivation of these keys are shown in the following diagram:
-
-.. figure:: zip-0227-key-components-zsa.png
-    :width: 450px
-    :align: center
-    :figclass: align-center
-
-    Diagram of Issuance Key Components for the ZSA Protocol
-
-
-Asset Identifier
-----------------
+Specification: 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.
 
@@ -159,13 +173,17 @@ The relations between the Asset Identifier, Asset Digest, and Asset Base are sho
     Diagram relating the Asset Identifier, Asset Digest, and Asset Base in the ZSA Protocol
 
 
-Global Issuance State
----------------------
+Specification: Global Issuance State
+====================================
 
 Issuance requires the following additions to the global state defined at block boundaries:
 
 - :math:`\mathsf{previously\_finalized}`, a set of :math:`\mathsf{AssetId}` that have been finalized (i.e.: the ``finalize`` flag has been set to ``1`` in some issuance transaction preceding the block boundary).
 
+
+Specification: Issuance Action, Issuance Bundle and Issuance Protocol
+=================================================================================
+
 Issuance Action Description
 ---------------------------
 
@@ -217,8 +235,8 @@ The issuer program performs the following operations
 For all actions `IssueAction`:
 
 - encode :math:`\mathsf{asset\_desc}` as a UTF-8 byte string of size up to 512.
-- compute :math:`\mathsf{AssetDigest}` from the issuance validating key :math:`\mathsf{ik}` and :math:`\mathsf{asset\_desc}` as decribed in the `Asset Identifier`_ section.
-- compute :math:`\mathsf{AssetBase^{Protocol}}` from :math:`\mathsf{AssetDigest}` as decribed in the `Asset Identifier`_ section.
+- compute :math:`\mathsf{AssetDigest}` from the issuance validating key :math:`\mathsf{ik}` and :math:`\mathsf{asset\_desc}` as decribed in the `Specification: Asset Identifier`_ section.
+- compute :math:`\mathsf{AssetBase^{Protocol}}` from :math:`\mathsf{AssetDigest}` as decribed in the `Specification: Asset Identifier`_ section.
 - 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``)
 - For each recipient :math:`i`:
 
@@ -236,8 +254,8 @@ For the `IssueBundle`:
 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`.
 
 
-Consensus Rule Changes
-----------------------
+Specification: Consensus Rule Changes
+=====================================
 
 For the IssueBundle:
 
@@ -247,7 +265,7 @@ For each `IssueAction` in `IssueBundle`:
 
 - check that :math:`0 < \mathsf{assetDescSize} <= 512`.
 - check that :math:`\mathsf{asset\_desc}` is a string of length :math:`\mathsf{assetDescSize}` bytes.
-- retrieve :math:`\mathsf{AssetBase}` from the first note in the sequence and check that :math:`\mathsf{AssetBase}` is derived from the issuance validating key :math:`\mathsf{ik}` and :math:`\mathsf{asset\_desc}` as described in the `Asset Identifier`_ section.
+- retrieve :math:`\mathsf{AssetBase}` from the first note in the sequence and check that :math:`\mathsf{AssetBase}` is derived from the issuance validating key :math:`\mathsf{ik}` and :math:`\mathsf{asset\_desc}` as described in the `Specification: Asset Identifier`_ section.
 - 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{AssetBase}` and is properly constructed as :math:`note = (\mathsf{g_d, pk_d, v, \rho, \psi, AssetBase})`.
 
@@ -444,6 +462,9 @@ References
 .. [#zip-0317b] `ZIP 317b: ZSA Extension Proportional Fee Mechanism <zip-0317b.html>`_
 .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.html>`_
 .. [#zip-0032-orchard-master] `ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation <zip-0032.html#orchard-master-key-generation>`_
+.. [#zip-0032-orchard-child-key-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard child key derivation <zip-0032.html#orchard-child-key-derivation>`_
+.. [#zip-0032-key-path-levels] `ZIP 32: Shielded Hierarchical Deterministic Wallets - Key path levels <zip-0032.html#key-path-levels>`_
+.. [#zip-0032-orchard-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard key path <zip-0032.html#orchard-key-path>`_
 .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys <zip-0316.html>`_
 .. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2022.3.8. Section 3.1: Payment Addresses and Keys <protocol/protocol.pdf#addressesandkeys>`_
 .. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2022.3.8. Section 5.4.9.8: Group Hash into Pallas and Vesta <protocol/protocol.pdf#concretegrouphashpallasandvesta>`_