ZIP 316, Revision 1: Clarify relation of "MUST-understand" typecodes to derivation.

Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Emma Hopwood 2024-01-18 19:36:50 +00:00
parent e05c7faa30
commit b0de22d1e2
2 changed files with 20 additions and 12 deletions

View File

@ -444,7 +444,8 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<p>Since an external P2PKH FVK encodes the chain code and public key at the Account level, we can derive both external and internal child keys from it, as described in BIP 44 <a id="footnote-reference-31" class="footnote_reference" href="#bip-0044-path-change">33</a>. It is possible to derive an internal P2PKH FVK from the external P2PKH FVK (i.e. its parent) without having the external spending key, because child derivation at the Change level is non-hardened.</p>
</section>
<section id="deriving-a-uivk-from-a-ufvk"><h3><span class="section-heading">Deriving a UIVK from a UFVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-uivk-from-a-ufvk"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As of <a href="#revision-1">Revision 1</a>, a Consumer of a UIVK MUST understand the meaning of all "MUST-understand" Metadata Item Typecodes present in the UFVK in order to perform UIVK derivation. For Metadata Items recognised by the Consumer, the processing of the Item when deriving a UIVK is specified in the section or ZIP describing that Item.</p>
<p>As a consequence of the specification in <a href="#must-understand-typecodes">MUST-understand Typecodes</a>, as of <a href="#revision-1">Revision 1</a> a Consumer of a UFVK MUST understand the meaning of all "MUST-understand" Metadata Item Typecodes present in the UFVK in order to derive a UIVK from it.</p>
<p>For Metadata Items recognised by the Consumer, the processing of the Item when deriving a UIVK is specified in the section or ZIP describing that Item.</p>
<p>The following derivations are applied to each component FVK:</p>
<ul>
<li>For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in <a id="footnote-reference-32" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
@ -457,7 +458,8 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<p>Items (including Metadata Items that are not "MUST-understand") that are unrecognised by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a UIVK from a UFVK.</p>
</section>
<section id="deriving-a-unified-address-from-a-uivk"><h3><span class="section-heading">Deriving a Unified Address from a UIVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-unified-address-from-a-uivk"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As of <a href="#revision-1">Revision 1</a>, a Consumer of a UIVK MUST understand the meaning of all "MUST-understand" Metadata Item Typecodes present in the UIVK in order to perform Unified Address derivation. For Metadata Items recognised by the Consumer, the processing of the Item when deriving a UIVK is specified in the section or ZIP describing that Item.</p>
<p>As a consequence of the specification in <a href="#must-understand-typecodes">MUST-understand Typecodes</a>, as of <a href="#revision-1">Revision 1</a> a Consumer of a UIVK MUST understand the meaning of all "MUST-understand" Metadata Item Typecodes present in the UIVK in order to derive a Unified Address from it.</p>
<p>For Metadata Items recognised by the Consumer, the processing of the Item when deriving a Unified Address is specified in the section or ZIP describing that Item.</p>
<p>To derive a Unified Address from a UIVK we need to choose a diversifier index, which MUST be valid for all of the Viewing Key Types in the UIVK. That is,</p>
<ul>
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="footnote-reference-35" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">17</a>.</li>

View File

@ -772,11 +772,14 @@ Change level is non-hardened.
Deriving a UIVK from a UFVK
---------------------------
As of `Revision 1`_, a Consumer of a UIVK MUST understand the
meaning of all "MUST-understand" Metadata Item Typecodes present in the
UFVK in order to perform UIVK derivation. For Metadata Items recognised
by the Consumer, the processing of the Item when deriving a UIVK is
specified in the section or ZIP describing that Item.
As a consequence of the specification in `MUST-understand Typecodes`_,
as of `Revision 1`_ a Consumer of a UFVK MUST understand the meaning of
all "MUST-understand" Metadata Item Typecodes present in the UFVK in
order to derive a UIVK from it.
For Metadata Items recognised by the Consumer, the processing of the
Item when deriving a UIVK is specified in the section or ZIP describing
that Item.
The following derivations are applied to each component FVK:
@ -801,11 +804,14 @@ dropped when deriving a UIVK from a UFVK.
Deriving a Unified Address from a UIVK
--------------------------------------
As of `Revision 1`_, a Consumer of a UIVK MUST understand the meaning
of all "MUST-understand" Metadata Item Typecodes present in the UIVK
in order to perform Unified Address derivation. For Metadata Items
recognised by the Consumer, the processing of the Item when deriving
a UIVK is specified in the section or ZIP describing that Item.
As a consequence of the specification in `MUST-understand Typecodes`_,
as of `Revision 1`_ a Consumer of a UIVK MUST understand the meaning of
all "MUST-understand" Metadata Item Typecodes present in the UIVK in
order to derive a Unified Address from it.
For Metadata Items recognised by the Consumer, the processing of the
Item when deriving a Unified Address is specified in the section or
ZIP describing that Item.
To derive a Unified Address from a UIVK we need to choose a diversifier
index, which MUST be valid for all of the Viewing Key Types in the