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

Merge pull request #588 from daira/zip-32-remove-sprout-hd 

ZIP 32: Remove Sprout-related specifications
This commit is contained in:
Daira Hopwood 2022-01-28 18:24:51 +00:00 committed by GitHub
parent de6dcad4df 7bd2845dbd
commit 2a4ab049b9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 61 additions and 260 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

198
zip-0032.html
View File

@ -35,9 +35,9 @@ License: MIT</pre>
<p>The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a tree of key components from a single seed, for the following shielded pools (which have different internal key structures):</p>
<ul>
<li>Sapling</li>
<li>Sprout (for compatibility, effectively unused)</li>
<li>Orchard</li>
</ul>
<p>Previous versions of this document also defined a similar derivation system for the Sprout shielded pool. This has been removed since it was never used, and is unlikely to be used given that <cite>zcashd</cite> no longer generates Sprout addresses (and neither <cite>Zebra</cite> nor the mobile SDKs have ever done so).</p>
<p>The last part shows how to use these trees in the context of existing BIP 44 <a id="id5" class="footnote_reference" href="#bip-0044">5</a> wallets.</p>
<p>This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses notwithstanding).</p>
</section>
@ -187,11 +187,6 @@ License: MIT</pre>
<span class="math">\(i' = i + 2^{31}\)</span>
) as in BIP 44 <a id="id14" class="footnote_reference" href="#bip-0044">5</a>:</p>
<ul>
<li>
<span class="math">\(\mathsf{CDKsk}(\mathsf{CDKsk}(\mathsf{CDKsk}(m_\mathsf{Sprout}, a'), b), c)\)</span>
is written as
<span class="math">\(m_\mathsf{Sprout} / a' / b / c\)</span>
</li>
<li>
<span class="math">\(\mathsf{CDKfvk}(\mathsf{CDKfvk}(\mathsf{CDKfvk}(m_\mathsf{Sapling}, a), b), c)\)</span>
is written as
@ -544,100 +539,8 @@ License: MIT</pre>
is the least nonnegative integer yielding a valid diversifier.</p>
</section>
</section>
<section id="specification-sprout-key-derivation"><h2><span class="section-heading">Specification: Sprout key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-sprout-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>For completeness, we define a system for deriving a tree of Sprout key components. It is unlikely that this will garner much usage once Sapling activates, but is presented for those users who may require it.</p>
<section id="sprout-extended-keys"><h3><span class="section-heading">Sprout extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-extended-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Due to the way Sprout keys are constructed and used, it is not possible to derive incoming viewing keys or payment addresses in parallel with spending keys. Nor is it possible to implement non-hardened derivation. We therefore only define and derive Sprout extended spending keys.</p>
<p>We represent a Sprout extended spending key as
<span class="math">\((\mathsf{a_{sk}, c})\)</span>
, where
<span class="math">\(\mathsf{a_{sk}}\)</span>
is the normal Sprout spending key, and
<span class="math">\(\mathsf{c}\)</span>
is the chain code.</p>
</section>
<section id="sprout-helper-functions"><h3><span class="section-heading">Sprout helper functions</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-helper-functions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Let
<span class="math">\(\mathsf{EncodeASK}(\mathsf{a_{sk}})\)</span>
be the 32-byte encoding of
<span class="math">\(\mathsf{a_{sk}}\)</span>
in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a id="id23" class="footnote_reference" href="#protocol-sproutspendingkeyencoding">17</a>.</p>
<p>Let
<span class="math">\(\mathsf{DecodeASK}(ASK)\)</span>
be the result of clearing the 4 most significant bits of the first byte of
<span class="math">\(ASK\)</span>
, and decoding the 32-byte result according to the inverse of
<span class="math">\(\mathsf{EncodeASK}\)</span>
.</p>
</section>
<section id="sprout-master-key-generation"><h3><span class="section-heading">Sprout master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-master-key-generation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Let
<span class="math">\(S\)</span>
be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.</p>
<ul>
<li>Calculate
<span class="math">\(I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32_Sprout”}, S)\)</span>
.</li>
<li>Split
<span class="math">\(I\)</span>
into two 32-byte sequences,
<span class="math">\(I_L\)</span>
and
<span class="math">\(I_R\)</span>
.</li>
<li>Use
<span class="math">\(\mathsf{DecodeASK}(I_L)\)</span>
as the master spending key
<span class="math">\(\mathsf{a}_{\mathsf{sk},m}\)</span>
.</li>
<li>Use
<span class="math">\(I_R\)</span>
as the master chain code
<span class="math">\(\mathsf{c}_m\)</span>
.</li>
</ul>
</section>
<section id="sprout-child-key-derivation"><h3><span class="section-heading">Sprout child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-child-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>
<span class="math">\(\mathsf{CDKsk}((\mathsf{a}_{\mathsf{sk},par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\mathsf{a}_{\mathsf{sk},i}, \mathsf{c}_i)\)</span>
</p>
<ul>
<li>Check whether
<span class="math">\(i \geq 2^{31}\)</span>
(whether the child is a hardened key).
<ul>
<li>If so (hardened child): let
<span class="math">\(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x80}]\)</span>
<span class="math">\(||\,\mathsf{EncodeASK}(\mathsf{a}_{\mathsf{sk},par})\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
.</li>
<li>If not (normal child): return failure.</li>
</ul>
</li>
<li>Split
<span class="math">\(I\)</span>
into two 32-byte sequences,
<span class="math">\(I_L\)</span>
and
<span class="math">\(I_R\)</span>
.</li>
<li>Use
<span class="math">\(\mathsf{DecodeASK}(I_L)\)</span>
as the child spending key
<span class="math">\(\mathsf{a}_{\mathsf{sk},i}\)</span>
.</li>
<li>Use
<span class="math">\(I_R\)</span>
as the child chain code
<span class="math">\(\mathsf{c}_i\)</span>
.</li>
</ul>
<p>There is no support for internal key derivation for Sprout.</p>
</section>
</section>
<section id="specification-orchard-key-derivation"><h2><span class="section-heading">Specification: Orchard key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-orchard-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The derivation mechanism for Sapling addresses specified above incurs significant complexity to support non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for non-hardened derivation appear. With that in mind, we define Orchard key derivation very similarly to Sprout above: only hardened derivation is supported.</p>
<p>The derivation mechanism for Sapling addresses specified above incurs significant complexity to support non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for non-hardened derivation appear. With that in mind, we only support hardened key derivation for Orchard.</p>
<section id="orchard-extended-keys"><h3><span class="section-heading">Orchard extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>We represent an Orchard extended spending key as
<span class="math">\((\mathsf{sk, c}),\)</span>
@ -720,7 +623,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="id24" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
be the corresponding external full viewing key, obtained as specified in <a id="id23" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
<ul>
<li>Let
<span class="math">\(K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
@ -742,12 +645,12 @@ 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="id25" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
fields being derived, as specified in <a id="id24" 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="id26" 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="id25" class="footnote_reference" href="#zip-0316">8</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>
@ -788,9 +691,9 @@ 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="id27" 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="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>
<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>Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
<p>Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
<ul>
<li>
<span class="math">\(purpose\)</span>
@ -801,7 +704,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="id28" 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="id27" 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>
@ -810,7 +713,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="id29" class="footnote_reference" href="#bip-0044">5</a>.</li>
in sequentially increasing manner. Defined as in BIP 44 <a id="id28" 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>
@ -832,7 +735,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="id30" class="footnote_reference" href="#bip-0044">5</a>:</p>
path level as in <a id="id29" class="footnote_reference" href="#bip-0044">5</a>:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
@ -844,14 +747,6 @@ License: MIT</pre>
<span class="math">\(address\_index\)</span>
.</p>
</section>
<section id="sprout-key-path"><h3><span class="section-heading">Sprout key path</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-key-path"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Wallets implementing Sprout ZIP 32 derivation MUST support the following path:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Sprout} / purpose' / coin\_type' / account' / address\_index\)</span>
.</li>
</ul>
</section>
<section id="orchard-key-path"><h3><span class="section-heading">Orchard key path</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-key-path"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.</p>
<p>The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard ZIP 32 derivation MUST support the following path for any account in range
@ -872,7 +767,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="id31" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">18</a>) is given by:</p>
(as specified in <a id="id30" 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>
@ -881,22 +776,10 @@ License: MIT</pre>
<p>It MAY be used to uniquely identify a particular Sapling full viewing key.</p>
<p>A "Sapling full viewing key tag" is the first 4 bytes of the corresponding Sapling full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.</p>
</section>
<section id="sprout-address-fingerprints-and-tags"><h3><span class="section-heading">Sprout Address Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-address-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding
<span class="math">\(\mathit{ADDR}\)</span>
(as specified in <a id="id32" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">16</a>, including the lead bytes) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, \mathit{ADDR})\)</span>
.</li>
</ul>
<p>It MAY be used to uniquely identify a particular Sprout payment address.</p>
<p>A "Sprout address tag" is the first 4 bytes of the corresponding Sprout address fingerprint. It is intended for optimizing performance of address lookups, and MUST NOT be assumed to uniquely identify a particular address.</p>
</section>
<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="id33" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a>) is given by:</p>
(as specified in <a id="id31" 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>
@ -921,7 +804,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="id34" 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="id32" 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>
@ -986,38 +869,6 @@ License: MIT</pre>
.</p>
<p>When encoded as Bech32, the Human-Readable Part is <code>zxviews</code> for the production network, or <code>zxviewtestsapling</code> for the test network.</p>
</section>
<section id="sprout-extended-spending-keys"><h3><span class="section-heading">Sprout extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-extended-spending-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A Sprout extended spending key
<span class="math">\((\mathsf{a_{sk}, c})\)</span>
, at depth
<span class="math">\(depth\)</span>
, with parent address tag
<span class="math">\(parent\_addr\_tag\)</span>
and child number
<span class="math">\(i\)</span>
, is represented as a byte sequence:</p>
<ul>
<li>
<span class="math">\(\mathsf{I2LEOSP}_{8}(depth)\)</span>
<span class="math">\(||\,parent\_addr\_tag\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i)\)</span>
<span class="math">\(||\,\mathsf{c}\)</span>
<span class="math">\(||\,\mathsf{EncodeASK}(\mathsf{a_{sk}})\)</span>
.</li>
</ul>
<p>For the master extended spending key,
<span class="math">\(depth\)</span>
is
<span class="math">\(0\)</span>
,
<span class="math">\(parent\_addr\_tag\)</span>
is 4 zero bytes, and
<span class="math">\(i\)</span>
is
<span class="math">\(0\)</span>
.</p>
<p>When encoded as Bech32, the Human-Readable Part is <code>zxsprout</code> for the production network, or <code>zxtestsprout</code> for the test network. Sprout extended spending keys are encoded using Bech32 even though other Sprout keys and addresses are encoded using Base58Check.</p>
</section>
<section id="orchard-extended-spending-keys"><h3><span class="section-heading">Orchard extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-spending-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An Orchard extended spending key
<span class="math">\((\mathsf{sk, c})\)</span>
@ -1045,9 +896,30 @@ 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="id35" 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="id33" 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>
<p>The following values were previously used in the specification of hierarchical derivation for Sprout, and therefore SHOULD NOT be used in future Zcash-related specifications:</p>
<ul>
<li>the BLAKE2b-256 personalizations
<ul>
<li>
<span class="math">\(\texttt{“ZcashIP32_Sprout”}\)</span>
, formerly specified for derivation of the master key of the Sprout tree;</li>
<li>
<span class="math">\(\texttt{“Zcash_Sprout_AFP”}\)</span>
, formerly specified for generation of Sprout address fingerprints;</li>
</ul>
</li>
<li>the
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
prefix
<span class="math">\(\texttt{0x80}\)</span>
, formerly specified for Sprout child key derivation;</li>
<li>the Bech32 Human-Readable Parts <code>zxsprout</code> and <code>zxtestsprout</code>, formerly specified for Sprout extended spending keys on Mainnet and Testnet respectively.</li>
</ul>
</section>
<section id="test-vectors"><h2><span class="section-heading">Test Vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBC</p>
</section>

123
zip-0032.rst
View File

@ -43,9 +43,12 @@ tree of key components from a single seed, for the following shielded pools (whi
key structures):
- Sapling
- Sprout (for compatibility, effectively unused)
- Orchard
Previous versions of this document also defined a similar derivation system for the Sprout shielded pool.
This has been removed since it was never used, and is unlikely to be used given that `zcashd` no longer
generates Sprout addresses (and neither `Zebra` nor the mobile SDKs have ever done so).
The last part shows how to use these trees in the context of existing BIP 44 [#bip-0044]_ wallets.
This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent
@ -137,7 +140,6 @@ specifications), which is the opposite of BIP 32.
We adapt the path notation of BIP 32 [#bip-0032]_ to describe shielded HD paths, using prime marks (:math:`'`) to
indicate hardened derivation (:math:`i' = i + 2^{31}`) as in BIP 44 [#bip-0044]_:
- :math:`\mathsf{CDKsk}(\mathsf{CDKsk}(\mathsf{CDKsk}(m_\mathsf{Sprout}, a'), b), c)` is written as :math:`m_\mathsf{Sprout} / a' / b / c`
- :math:`\mathsf{CDKfvk}(\mathsf{CDKfvk}(\mathsf{CDKfvk}(m_\mathsf{Sapling}, a), b), c)` is written as :math:`m_\mathsf{Sapling} / a / b / c`.
@ -335,66 +337,12 @@ The default diversifier for a Sapling extended key is defined to be :math:`d_j`,
least nonnegative integer yielding a valid diversifier.
Specification: Sprout key derivation
====================================
For completeness, we define a system for deriving a tree of Sprout key components. It is unlikely that this
will garner much usage once Sapling activates, but is presented for those users who may require it.
Sprout extended keys
--------------------
Due to the way Sprout keys are constructed and used, it is not possible to derive incoming viewing keys or
payment addresses in parallel with spending keys. Nor is it possible to implement non-hardened derivation.
We therefore only define and derive Sprout extended spending keys.
We represent a Sprout extended spending key as :math:`(\mathsf{a_{sk}, c})`, where :math:`\mathsf{a_{sk}}`
is the normal Sprout spending key, and :math:`\mathsf{c}` is the chain code.
Sprout helper functions
-----------------------
Let :math:`\mathsf{EncodeASK}(\mathsf{a_{sk}})` be the 32-byte encoding of :math:`\mathsf{a_{sk}}` in the
raw encoding of a Sprout spending key (excluding lead bytes) as specified in [#protocol-sproutspendingkeyencoding]_.
Let :math:`\mathsf{DecodeASK}(ASK)` be the result of clearing the 4 most significant bits of the first byte
of :math:`ASK`, and decoding the 32-byte result according to the inverse of :math:`\mathsf{EncodeASK}`.
Sprout master key generation
----------------------------
Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
- Calculate :math:`I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32_Sprout”}, S)`.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Use :math:`\mathsf{DecodeASK}(I_L)` as the master spending key :math:`\mathsf{a}_{\mathsf{sk},m}`.
- Use :math:`I_R` as the master chain code :math:`\mathsf{c}_m`.
Sprout child key derivation
---------------------------
:math:`\mathsf{CDKsk}((\mathsf{a}_{\mathsf{sk},par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{a}_{\mathsf{sk},i}, \mathsf{c}_i)`
- Check whether :math:`i \geq 2^{31}` (whether the child is a hardened key).
- If so (hardened child): let
:math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x80}]`:math:`||\,\mathsf{EncodeASK}(\mathsf{a}_{\mathsf{sk},par})`:math:`||\,\mathsf{I2LEOSP}_{32}(i))`.
- If not (normal child): return failure.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Use :math:`\mathsf{DecodeASK}(I_L)` as the child spending key :math:`\mathsf{a}_{\mathsf{sk},i}`.
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
There is no support for internal key derivation for Sprout.
Specification: Orchard key derivation
=====================================
The derivation mechanism for Sapling addresses specified above incurs significant complexity to support
non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for
non-hardened derivation appear. With that in mind, we define Orchard key derivation very similarly to
Sprout above: only hardened derivation is supported.
non-hardened derivation appear. With that in mind, we only support hardened key derivation for Orchard.
Orchard extended keys
---------------------
@ -500,8 +448,8 @@ altered the design where it makes sense to leverage features of shielded address
Key path levels
---------------
Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use
hardened derivation:
Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened
derivation:
- :math:`purpose`: a constant set to :math:`32'` (or :math:`\texttt{0x80000020}`) following the BIP 43
recommendation. It indicates that the subtree of this node is used according to this specification.
@ -550,13 +498,6 @@ they MAY additionally support a non-hardened :math:`address\_index` path level a
`zcashd` version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase
under account :math:`\mathtt{0x7FFFFFFF}`, using hardened derivation for :math:`address\_index`.
Sprout key path
---------------
Wallets implementing Sprout ZIP 32 derivation MUST support the following path:
* :math:`m_\mathsf{Sprout} / purpose' / coin\_type' / account' / address\_index`.
Orchard key path
----------------
@ -596,20 +537,6 @@ A "Sapling full viewing key tag" is the first 4 bytes of the corresponding Sapli
fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to
uniquely identify a particular key.
Sprout Address Fingerprints and Tags
------------------------------------
A "Sprout address fingerprint" of a Sprout payment address with raw encoding :math:`\mathit{ADDR}` (as specified in
[#protocol-sproutpaymentaddrencoding]_, including the lead bytes) is given by:
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, \mathit{ADDR})`.
It MAY be used to uniquely identify a particular Sprout payment address.
A "Sprout address tag" is the first 4 bytes of the corresponding Sprout address fingerprint. It is
intended for optimizing performance of address lookups, and MUST NOT be assumed to uniquely identify
a particular address.
Orchard Full Viewing Key Fingerprints and Tags
----------------------------------------------
@ -677,23 +604,6 @@ is 4 zero bytes, and :math:`i` is :math:`0`.
When encoded as Bech32, the Human-Readable Part is ``zxviews`` for the production
network, or ``zxviewtestsapling`` for the test network.
Sprout extended spending keys
-----------------------------
A Sprout extended spending key :math:`(\mathsf{a_{sk}, c})`, at depth :math:`depth`, with
parent address tag :math:`parent\_addr\_tag` and child number :math:`i`, is represented as a
byte sequence:
* :math:`\mathsf{I2LEOSP}_{8}(depth)`:math:`||\,parent\_addr\_tag`:math:`||\,\mathsf{I2LEOSP}_{32}(i)`:math:`||\,\mathsf{c}`:math:`||\,\mathsf{EncodeASK}(\mathsf{a_{sk}})`.
For the master extended spending key, :math:`depth` is :math:`0`, :math:`parent\_addr\_tag`
is 4 zero bytes, and :math:`i` is :math:`0`.
When encoded as Bech32, the Human-Readable Part is ``zxsprout`` for the production
network, or ``zxtestsprout`` for the test network. Sprout extended spending keys
are encoded using Bech32 even though other Sprout keys and addresses are encoded
using Base58Check.
Orchard extended spending keys
------------------------------
@ -713,6 +623,25 @@ spending keys, we expect that most wallets will only expose the regular Orchard
users [#protocol-orchardspendingkeyencoding]_.
Values reserved due to previous specification for Sprout
========================================================
The following values were previously used in the specification of hierarchical derivation
for Sprout, and therefore SHOULD NOT be used in future Zcash-related specifications:
* the BLAKE2b-256 personalizations
* :math:`\texttt{“ZcashIP32_Sprout”}`, formerly specified for derivation of the master
key of the Sprout tree;
* :math:`\texttt{“Zcash_Sprout_AFP”}`, formerly specified for generation of Sprout
address fingerprints;
* the :math:`\mathsf{PRF^{expand}}` prefix :math:`\texttt{0x80}`, formerly specified for
Sprout child key derivation;
* the Bech32 Human-Readable Parts ``zxsprout`` and ``zxtestsprout``, formerly specified for
Sprout extended spending keys on Mainnet and Testnet respectively.
Test Vectors
============