Adding issuance key derivation details #8
Conversation
✅ Deploy Preview for zcash-zips-qedit ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
zip-0227.rst
Outdated
| As in ZIP 32 for Orchard [#zip-0032-orchard-child-key-derivation]_, we only use hardened child key derivation for issuance master key. | ||
| We define the following function for child key derivation: | ||
|
|
||
| :math:`\mathsf{CDKik}((\mathsf{sk}_{par},\mathsf{c}_{par}),i) \to (\mathsf{sk}_i, \mathsf{c}_i)` | ||
|
|
||
| - Check whether :math:`i \geq 2^{31}` (i.e. whether the child is a hardened key) | ||
|
|
||
| - If so (hardened child): Let :math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\mathtt{0xa1}] \| \mathsf{sk}_{par} \| \mathsf{I2LEOSP}_{32}(i))`. | ||
| - If not (non-hardened child): return failure. | ||
|
|
||
| - Split :math:`I` into two 32-byte sequences :math:`I_L` and :math:`I_R`. | ||
| - Set :math:`(\mathsf{sk}_i, \mathsf{c}_i) = (I_L, I_R)`. |
There was a problem hiding this comment.
The 0xa1 "personalization" is the only thing changed from the Orchard definition of the CDKsk function. But this domain separation seems necessary, so it required defining a fresh function (that I named CDKik for clarity)
zip-0227.rst
Outdated
| - :math:`coin\_type`: a constant identifying the cryptocurrency that this subtree's keys are used with. We use the same constants as defined in SLIP 44 | ||
| [#slip-0044]_ for ZEC, namely :math:`\texttt{0x80000085}`. Also, in keeping with that document, all cryptocurrency testnets share :math:`coin\_type` index :math:`1`. |
There was a problem hiding this comment.
I explicitly fixed it to the ZEC value, because if we write it the way it is written in ZIP 32, it could be taken to mean that if we are issuing a wrapped BTC we should use the coin_type for BTC, and so on.
I think fixing it to ZEC seems to be the best approach, but suggestions are welcome.
|
|
||
| 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]_. | ||
|
|
||
| Issuance master key derivation for hierarchical deterministic wallets |
There was a problem hiding this comment.
Avoid bold headers, the header style should be similar to https://deploy-preview-8--zcash-zips-qedit.netlify.app/zip-0032.html#specification-orchard-key-derivation
zip-0227.rst
Outdated
| 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]_. |
There was a problem hiding this comment.
This section seems out of place, I would put after the keys, just before https://deploy-preview-8--zcash-zips-qedit.netlify.app/zip-0227#asset-identifier
There was a problem hiding this comment.
The reason for defining it first is that IssueAuthSig is used in the Derivation of issuance authorizing key and issuance validating key section, so it needed to be defined before that.
|
|
||
| - :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`. |
There was a problem hiding this comment.
Is the account index equals to i from above? if so, should be specified. If not, what is i?
There was a problem hiding this comment.
The i in the CDKsk definition is just the argument of the terms in the path - so m / a / b / c signifies CDKsk(CDKsk(CDKsk(m,a),b),c).
After the change to use the same CDKsk as in Orchard, we no longer have this i in our spec.
| 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]_. |
There was a problem hiding this comment.
str4d and Daira had recommended against putting in the explicit 0x80000085 value in the earlier meeting, because someone who forks the repo should know not to hardcode it. They had said it would need rewording in ZIP 32 to specify it is to be set to the base cryptocurrency (aka ZEC for us), so I have left it to be the same as in ZIP 32 for now.
vivek-arte
force-pushed
the
issuance_key_derivation
branch
from
5dfae8f
to
6bfd6a2
Compare
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).
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).
This PR contains the changes to the Issuance ZIP for the derivation of the issuance keys based on the techniques from ZIP 32.