zecfoundation
/
zips
mirror of https://github.com/ZcashFoundation/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 32: Point out that Sapling and Orchard keys can be invalid. 

fixes #561

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2022-04-28 16:37:25 +01:00
parent fb223c206d
commit d9ab7909ec
2 changed files with 84 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
zip-0032.html
View File

@ -297,6 +297,15 @@ License: MIT</pre>
<span class="math">\(m_\mathsf{Sapling}\)</span>
.</li>
</ul>
<p>Note that the master extended key is invalid if
<span class="math">\(\mathsf{ask}_m\)</span>
is
<span class="math">\(0\)</span>
, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
<section id="sapling-child-key-derivation"><h3><span class="section-heading">Sapling child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-child-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index
@ -325,7 +334,7 @@ License: MIT</pre>
<span class="math">\((\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})\)</span>
is the full viewing key derived from
<span class="math">\((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})\)</span>
as described in <a id="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
as described in <a id="id17" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
</ul>
</li>
<li>Split
@ -363,13 +372,22 @@ License: MIT</pre>
</ul>
</li>
</ul>
<p>Note that the child extended key is invalid if
<span class="math">\(\mathsf{ask}_i\)</span>
is
<span class="math">\(0\)</span>
, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id18" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
<section id="deriving-a-child-extended-full-viewing-key"><h4><span class="section-heading">Deriving a child extended full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-full-viewing-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\(\mathcal{G}^\mathsf{Sapling}\)</span>
be as defined in <a id="id17" class="footnote_reference" href="#protocol-concretespendauthsig">14</a> and let
be as defined in <a id="id19" class="footnote_reference" href="#protocol-concretespendauthsig">14</a> and let
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
be as defined in <a id="id18" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
be as defined in <a id="id20" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
<p>
<span class="math">\(\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})\)</span>
@ -422,10 +440,17 @@ License: MIT</pre>
</ul>
</li>
</ul>
<p>Note that the child extended key is invalid if
<span class="math">\(\mathsf{ak}_i\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id21" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
</section>
<section id="sapling-internal-key-derivation"><h3><span class="section-heading">Sapling internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree <a id="id19" class="footnote_reference" href="#bip-0044">5</a>, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
<p>The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree <a id="id22" class="footnote_reference" href="#bip-0044">5</a>, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
<section id="deriving-a-sapling-internal-spending-key"><h4><span class="section-heading">Deriving a Sapling internal spending key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-spending-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})\)</span>
@ -435,7 +460,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{ak}\)</span>
and
<span class="math">\(\mathsf{nk}\)</span>
as specified in <a id="id20" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
as specified in <a id="id23" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
<li>Let
<span class="math">\(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\)</span>
.</li>
@ -459,11 +484,18 @@ License: MIT</pre>
<span class="math">\((\mathsf{ask}, \mathsf{nsk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})\)</span>
.</li>
</ul>
<p>Note that the child extended key is invalid if
<span class="math">\(\mathsf{ak}\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
<section id="deriving-a-sapling-internal-full-viewing-key"><h4><span class="section-heading">Deriving a Sapling internal full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-full-viewing-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
be as defined in <a id="id21" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
be as defined in <a id="id25" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
<p>Let
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)</span>
be the external full viewing key.</p>
@ -506,7 +538,14 @@ License: MIT</pre>
<figcaption>Diagram of Sapling internal key derivation</figcaption>
</figure>
<p>(For simplicity, the proof authorizing key is not shown.)</p>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id22" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id26" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>Note that the internal extended key is invalid if
<span class="math">\(\mathsf{ak}\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
derived from the internal full viewing key as specified in <a id="id27" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
</section>
<section id="sapling-diversifier-derivation"><h3><span class="section-heading">Sapling diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-diversifier-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -616,6 +655,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{c}_i\)</span>
.</li>
</ul>
<p>Note that the resulting child spending key may produce an invalid external FVK, as specified in <a id="id28" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.</p>
</section>
<section id="orchard-internal-key-derivation"><h3><span class="section-heading">Orchard internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As in the case of Sapling, for a given external address, we want to produce another address for use by wallets for internal operations such as change and auto-shielding. That is, for any external full viewing key we need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
@ -623,7 +663,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{ask}\)</span>
be the spend authorizing key if available, and let
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
be the corresponding external full viewing key, obtained as specified in <a id="id23" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
be the corresponding external full viewing key, obtained as specified in <a id="id29" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
<p>Define
<span class="math">\(\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
as follows:</p>
@ -651,12 +691,13 @@ License: MIT</pre>
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
and
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
fields being derived, as specified in <a id="id24" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
fields being derived, as specified in <a id="id30" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
<figure class="align-center" align="center">
<img width="720px" src="zip-0032-orchard-internal-key-derivation.png" />
<figcaption>Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key</figcaption>
</figure>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id25" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id31" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>Note that the resulting FVK may be invalid, as specified in <a id="id32" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
</section>
<section id="orchard-diversifier-derivation"><h3><span class="section-heading">Orchard diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-diversifier-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending key. This means that the full viewing key provides the capability to determine the position of a diversifier within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the key structure.</p>
@ -697,7 +738,7 @@ License: MIT</pre>
</section>
</section>
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a rel="bookmark" href="#specification-wallet-usage"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id26" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id33" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a rel="bookmark" href="#key-path-levels"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
<ul>
@ -710,7 +751,7 @@ License: MIT</pre>
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.</li>
<li>
<span class="math">\(coin\_type\)</span>
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id27" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id34" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
<span class="math">\(coin\_type\)</span>
index
<span class="math">\(1\)</span>
@ -719,7 +760,7 @@ License: MIT</pre>
<span class="math">\(account\)</span>
: numbered from index
<span class="math">\(0\)</span>
in sequentially increasing manner. Defined as in BIP 44 <a id="id28" class="footnote_reference" href="#bip-0044">5</a>.</li>
in sequentially increasing manner. Defined as in BIP 44 <a id="id35" class="footnote_reference" href="#bip-0044">5</a>.</li>
</ul>
<p>Unlike BIP 44, none of the shielded key paths have a
<span class="math">\(change\)</span>
@ -741,7 +782,7 @@ License: MIT</pre>
payment addresses, because each diversifier has around a 50% chance of being invalid.</p>
<p>If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened
<span class="math">\(address\_index\)</span>
path level as in <a id="id29" class="footnote_reference" href="#bip-0044">5</a>:</p>
path level as in <a id="id36" class="footnote_reference" href="#bip-0044">5</a>:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
@ -773,7 +814,7 @@ License: MIT</pre>
<section id="sapling-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Sapling Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(\mathit{FVK}\)</span>
(as specified in <a id="id30" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">18</a>) is given by:</p>
(as specified in <a id="id37" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">18</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\)</span>
@ -785,7 +826,7 @@ License: MIT</pre>
<section id="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(\mathit{FVK}\)</span>
(as specified in <a id="id31" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a>) is given by:</p>
(as specified in <a id="id38" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\)</span>
@ -810,7 +851,7 @@ License: MIT</pre>
</section>
</section>
<section id="specification-key-encodings"><h2><span class="section-heading">Specification: Key Encodings</span><span class="section-anchor"> <a rel="bookmark" href="#specification-key-encodings"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id32" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id39" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
<section id="sapling-extended-spending-keys"><h3><span class="section-heading">Sapling extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-spending-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A Sapling extended spending key
<span class="math">\((\mathsf{ask, nsk, ovk, dk, c})\)</span>
@ -902,7 +943,7 @@ License: MIT</pre>
<span class="math">\(0\)</span>
.</p>
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-orchard-extsk-main</code> for Mainnet, or <code>secret-orchard-extsk-test</code> for Testnet.</p>
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id33" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id40" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
</section>
</section>
<section id="values-reserved-due-to-previous-specification-for-sprout"><h2><span class="section-heading">Values reserved due to previous specification for Sprout</span><span class="section-anchor"> <a rel="bookmark" href="#values-reserved-due-to-previous-specification-for-sprout"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>

25
zip-0032.rst
View File

@ -202,6 +202,9 @@ Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least
- Return :math:`(\mathsf{ask}_m, \mathsf{nsk}_m, \mathsf{ovk}_m, \mathsf{dk}_m, \mathsf{c}_m)` as the
master extended spending key :math:`m_\mathsf{Sapling}`.
Note that the master extended key is invalid if :math:`\mathsf{ask}_m` is :math:`0`, or if the corresponding
:math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
Sapling child key derivation
----------------------------
@ -233,6 +236,9 @@ Deriving a child extended spending key
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
- :math:`\mathsf{c}_i = I_R`.
Note that the child extended key is invalid if :math:`\mathsf{ask}_i` is :math:`0`, or if the corresponding
:math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
Deriving a child extended full viewing key
``````````````````````````````````````````
@ -258,6 +264,10 @@ let :math:`\mathcal{H}^\mathsf{Sapling}` be as defined in [#protocol-saplingkeyc
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
- :math:`\mathsf{c}_i = I_R`.
Note that the child extended key is invalid if :math:`\mathsf{ak}_i` is the zero point of Jubjub,
or if the corresponding :math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_
is :math:`0`.
Sapling internal key derivation
-------------------------------
@ -283,6 +293,10 @@ Let :math:`(\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})` be the exter
- Split :math:`R` into two 32-byte sequences, :math:`\mathsf{dk_{internal}}` and :math:`\mathsf{ovk_{internal}}`.
- Return the internal spending key as :math:`(\mathsf{ask}, \mathsf{nsk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})`.
Note that the child extended key is invalid if :math:`\mathsf{ak}` is the zero point of Jubjub,
or if the corresponding :math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_
is :math:`0`.
Deriving a Sapling internal full viewing key
````````````````````````````````````````````
@ -317,6 +331,11 @@ are shown in the following diagram:
This method of deriving internal keys is applied to external keys that are children of the
Account level. It was implemented in `zcashd` as part of support for ZIP 316 [#zip-0316]_.
Note that the internal extended key is invalid if :math:`\mathsf{ak}` is the zero point of Jubjub,
or if the corresponding :math:`\mathsf{ivk_{internal}}` derived from the internal full viewing key
as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
Sapling diversifier derivation
------------------------------
@ -377,6 +396,10 @@ Orchard child key derivation
- Use :math:`I_L` as the child spending key :math:`\mathsf{sk}_{i}`.
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
Note that the resulting child spending key may produce an invalid external FVK, as specified
in [#protocol-orchardkeycomponents]_, with small probability. The corresponding internal FVK
derived as specified in the next section may also be invalid with small probability.
Orchard internal key derivation
-------------------------------
@ -419,6 +442,8 @@ diagram:
This method of deriving internal keys is applied to external keys that are children of the
Account level. It was implemented in `zcashd` as part of support for ZIP 316 [#zip-0316]_.
Note that the resulting FVK may be invalid, as specified in [#protocol-orchardkeycomponents]_.
Orchard diversifier derivation
------------------------------