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

ZIP 32: Specify Orchard key derivation

This commit is contained in:
Jack Grigg 2021-02-27 14:59:32 +00:00 committed by Daira Hopwood
parent 7350f94b0e
commit f2eb24ae6e
4 changed files with 310 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

179
zip-0032.html
View File

@ -27,7 +27,13 @@ License: MIT</pre>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id3" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
<p>The specification has three parts. The first part defines a system for deriving a tree of Sapling key components from a single seed. The second part defines an equivalent, but independent, system for Sprout key components (which have a different internal construction). The third part shows how to use these trees in the context of existing BIP 44 <a id="id4" class="footnote_reference" href="#bip-0044">5</a> wallets.</p>
<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>The last part shows how to use these trees in the context of existing BIP 44 <a id="id4" 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>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -41,7 +47,7 @@ License: MIT</pre>
<p>At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.</p>
</section>
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification <a id="id8" class="footnote_reference" href="#protocol">8</a>. They are reproduced here for convenience:</p>
<p>Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification <a id="id8" class="footnote_reference" href="#protocol">8</a>. They are reproduced here for convenience:</p>
<ul>
<li>
<span class="math">\(\mathsf{truncate}_k(S)\)</span>
@ -162,7 +168,7 @@ License: MIT</pre>
<span class="math">\(\mathsf{LEOS2IP}_\ell(S)\)</span>
.</li>
</ul>
<p>Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling specification), which is the opposite of BIP 32.</p>
<p>Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard specifications), which is the opposite of BIP 32.</p>
<p>We adapt the path notation of BIP 32 <a id="id12" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
<span class="math">\('\)</span>
) to indicate hardened derivation (
@ -411,7 +417,7 @@ License: MIT</pre>
</ul>
</section>
</section>
<section id="diversifier-derivation"><h3><span class="section-heading">Diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#diversifier-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key
<span class="math">\(\mathsf{dk}\)</span>
. To prevent the diversifier leaking how many diversified addresses have already been generated for an account, we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account. In order to reach the maximum possible diversifier range without running into repetitions due to the birthday bound, we use FF1-AES256 as a Pseudo-Random Permutation as follows:</p>
@ -532,10 +538,115 @@ License: MIT</pre>
</ul>
</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" 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>
<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" 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>
where
<span class="math">\(\mathsf{sk}\)</span>
is the normal Orchard spending key (opaque 32 bytes), and
<span class="math">\(\mathsf{c}\)</span>
is the chain code.</p>
</section>
<section id="orchard-master-key-generation"><h3><span class="section-heading">Orchard master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-master-key-generation"><img width="24" height="24" 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{“ZcashIP32Orchard”}, 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">\(I_L\)</span>
as the master spending key
<span class="math">\(\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="orchard-child-key-derivation"><h3><span class="section-heading">Orchard child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-child-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>
<span class="math">\(\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\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{0x81}]\,||\,\mathsf{sk}_{par}\,||\,\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">\(I_L\)</span>
as the child spending key
<span class="math">\(\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>
</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" 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. Given an Orchard extended spending key
<span class="math">\((\mathsf{sk}_i, \mathsf{c}_i)\)</span>
:</p>
<ul>
<li>Let
<span class="math">\(\mathsf{fvk}_i\)</span>
be the raw encoding of the Orchard full viewing key for
<span class="math">\(\mathsf{sk}_i\)</span>
(as specified in TODO).</li>
<li>
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{fvk}_i, [\texttt{0x82}]))\)</span>
.</li>
<li>Let
<span class="math">\(j\)</span>
be the index of the desired diversifier, in the range
<span class="math">\(0\,.\!. 2^{88} - 1\)</span>
.</li>
<li>
<span class="math">\(d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\)</span>
.</li>
</ul>
<p>Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of
<span class="math">\(j\)</span>
yield valid diversifiers.</p>
<p>The default diversifier for
<span class="math">\((\mathsf{sk}_i, \mathsf{c}_i)\)</span>
is defined to be
<span class="math">\(d_{i,0}.\)</span>
</p>
</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id19" 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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Both Sprout and Sapling key paths have the following three path levels at the top, all of which use hardened derivation:</p>
<p>Sprout, 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>
@ -557,7 +668,7 @@ License: MIT</pre>
<span class="math">\(0\)</span>
in sequentially increasing manner. Defined as in BIP 44 <a id="id21" class="footnote_reference" href="#bip-0044">5</a>.</li>
</ul>
<p>Unlike BIP 44, neither Sprout nor Sapling have a
<p>Unlike BIP 44, none of the shielded key paths have a
<span class="math">\(change\)</span>
path level. The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating external and internal address usage. Shielded addresses are never publicly visible in transactions, which means that sending change back to the originating address is indistinguishable from using a change address.</p>
</section>
@ -592,6 +703,21 @@ License: MIT</pre>
.</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" 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
<span class="math">\(\{ 0\,.\!. 2^{31} - 1 \}\)</span>
:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Orchard} / purpose' / coin\_type' / account'\)</span>
.</li>
</ul>
<p>Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of payment addresses for a given account, if they wish to maintain the user experience of giving a unique address to each recipient.</p>
<p>Note that a given account can have a maximum of
<span class="math">\(2^{88}\)</span>
payment addresses (unlike Sapling, all Orchard diversifiers are valid).</p>
</section>
</section>
<section id="specification-fingerprints-and-tags"><h2><span class="section-heading">Specification: Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#specification-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -618,6 +744,18 @@ License: MIT</pre>
<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" 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">\(FVK\)</span>
(as specified in TODO) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, FVK)\)</span>
.</li>
</ul>
<p>It MAY be used to uniquely identify a particular Orchard full viewing key.</p>
<p>An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard 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="seed-fingerprints"><h3><span class="section-heading">Seed Fingerprints</span><span class="section-anchor"> <a rel="bookmark" href="#seed-fingerprints"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "seed fingerprint" for the master seed
<span class="math">\(S\)</span>
@ -731,6 +869,35 @@ License: MIT</pre>
.</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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An Orchard extended spending key
<span class="math">\((\mathsf{sk, c})\)</span>
, at depth
<span class="math">\(depth\)</span>
, with parent full viewing key tag
<span class="math">\(parent\_fvk\_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)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{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\_fvk\_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>secret-orchard-extsk-main</code> for the production network, or <code>secret-orchard-extsk-test</code> for the test network.</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 (TODO: reference).</p>
</section>
</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBC</p>

142
zip-0032.rst
View File

@ -29,10 +29,15 @@ Abstract
This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32
[#bip-0032]_, to support Zcash's shielded addresses.
The specification has three parts. The first part defines a system for deriving a tree of Sapling key
components from a single seed. The second part defines an equivalent, but independent, system for Sprout key
components (which have a different internal construction). The third part shows how to use these trees in the
context of existing BIP 44 [#bip-0044]_ wallets.
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):
- Sapling
- Sprout (for compatibility, effectively unused)
- Orchard
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
Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses
@ -63,7 +68,7 @@ shielded addresses, it is desirable to have a standard mechanism for deriving th
Conventions
===========
Most of the notation and functions used in this ZIP are defined in the Sapling protocol specification
Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification
[#protocol]_. They are reproduced here for convenience:
- :math:`\mathsf{truncate}_k(S)` means the sequence formed from the first :math:`k` elements of :math:`S`.
@ -113,8 +118,8 @@ We also define the following conversion function:
little-endian order the integer :math:`k` in range :math:`\{ 0\,.\!. 2^\ell - 1 \}`. It is the reverse
operation of :math:`\mathsf{LEOS2IP}_\ell(S)`.
Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling
specification), which is the opposite of BIP 32.
Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard
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]_:
@ -238,8 +243,8 @@ in [#protocol-saplingkeycomponents]_.
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
- :math:`\mathsf{c}_i = I_R`.
Diversifier derivation
----------------------
Sapling diversifier derivation
------------------------------
The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key :math:`\mathsf{dk}`.
To prevent the diversifier leaking how many diversified addresses have already been generated for an account,
@ -309,6 +314,64 @@ Sprout child key derivation
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
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.
Orchard extended keys
---------------------
We represent an Orchard extended spending key as :math:`(\mathsf{sk, c}),` where :math:`\mathsf{sk}`
is the normal Orchard spending key (opaque 32 bytes), and :math:`\mathsf{c}` is the chain code.
Orchard 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{“ZcashIP32Orchard”}, S)`.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Use :math:`I_L` as the master spending key :math:`\mathsf{sk}_m`.
- Use :math:`I_R` as the master chain code :math:`\mathsf{c}_m`.
Orchard child key derivation
----------------------------
:math:`\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\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{0x81}]\,||\,\mathsf{sk}_{par}\,||\,\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:`I_L` as the child spending key :math:`\mathsf{sk}_{i}`.
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
Orchard diversifier derivation
------------------------------
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. Given an Orchard extended
spending key :math:`(\mathsf{sk}_i, \mathsf{c}_i)`:
- Let :math:`\mathsf{fvk}_i` be the raw encoding of the Orchard full viewing key for :math:`\mathsf{sk}_i`
(as specified in TODO).
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{fvk}_i, [\texttt{0x82}]))`.
- Let :math:`j` be the index of the desired diversifier, in the range :math:`0\,.\!. 2^{88} - 1`.
- :math:`d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))`.
Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of :math:`j` yield
valid diversifiers.
The default diversifier for :math:`(\mathsf{sk}_i, \mathsf{c}_i)` is defined to be :math:`d_{i,0}.`
Specification: Wallet usage
===========================
@ -319,8 +382,8 @@ altered the design where it makes sense to leverage features of shielded address
Key path levels
---------------
Both Sprout and Sapling key paths have the following three path levels at the top, all of which use hardened
derivation:
Sprout, 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.
@ -333,8 +396,8 @@ derivation:
- :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in
BIP 44 [#bip-0044]_.
Unlike BIP 44, neither Sprout nor Sapling have a :math:`change` path level. The use of change addresses in
Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by
Unlike BIP 44, none of the shielded key paths have a :math:`change` path level. The use of change addresses
in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by
segregating external and internal address usage. Shielded addresses are never publicly visible in
transactions, which means that sending change back to the originating address is indistinguishable from
using a change address.
@ -373,6 +436,27 @@ Wallets implementing Sprout ZIP 32 derivation MUST support the following path:
* :math:`m_\mathsf{Sprout} / purpose' / coin\_type' / account' / address\_index`.
Orchard key path
----------------
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.
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 :math:`\{ 0\,.\!. 2^{31} - 1 \}`:
* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account'`.
Furthermore, wallets MUST support generating the default payment address (corresponding to the default
diversifier for Orchard) for any account they support. They MAY also support generating a stream of payment
addresses for a given account, if they wish to maintain the user experience of giving a unique address to
each recipient.
Note that a given account can have a maximum of :math:`2^{88}` payment addresses (unlike Sapling, all Orchard
diversifiers are valid).
Specification: Fingerprints and Tags
====================================
@ -405,6 +489,20 @@ A "Sprout address tag" is the first 4 bytes of the corresponding Sprout address
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
----------------------------------------------
An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding :math:`FVK` (as specified
in TODO) is given by:
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, FVK)`.
It MAY be used to uniquely identify a particular Orchard full viewing key.
An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard full viewing key
fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to
uniquely identify a particular key.
Seed Fingerprints
-----------------
@ -475,6 +573,24 @@ 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
------------------------------
An Orchard extended spending key :math:`(\mathsf{sk, c})`, at depth :math:`depth`, with parent full viewing
key tag :math:`parent\_fvk\_tag` and child number :math:`i`, is represented as a byte sequence:
* :math:`\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}`.
For the master extended spending key, :math:`depth` is :math:`0`, :math:`parent\_fvk\_tag` is
4 zero bytes, and :math:`i` is :math:`0`.
When encoded as Bech32, the Human-Readable Part is ``secret-orchard-extsk-main``
for the production network, or ``secret-orchard-extsk-test`` for the test network.
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 (TODO: reference).
Test Vectors
============

15
zip-0224.html
View File

@ -92,17 +92,12 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<li>All diversifiers now result in valid payment addresses.</li>
</ul>
<p>Keys and addresses are encoded using Bech32. Orchard addresses used with the Zcash mainnet have the prefix "zo" (compared to "zc" for Sprout and "zs" for Sapling).</p>
<p>Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 <a id="id15" class="footnote_reference" href="#zip-0032">23</a> to Orchard; instead, we define a simple hardened-only derivation mechanism.</p>
<p>Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only derivation mechanism (similar to Sprout).</p>
<ul>
<li>Key components diagram: <a id="id16" class="footnote_reference" href="#spec-addrs-keys">2</a></li>
<li>Key components specification: <a id="id17" class="footnote_reference" href="#spec-keys">6</a></li>
<li>Encodings and HRPs: <a id="id18" class="footnote_reference" href="#spec-encoding-addr">12</a> <a id="id19" class="footnote_reference" href="#spec-encoding-ivk">13</a> <a id="id20" class="footnote_reference" href="#spec-encoding-fvk">14</a> <a id="id21" class="footnote_reference" href="#spec-encoding-sk">15</a></li>
<li>HD key derivation specification: TODO
<ul>
<li>Needs to be hierarchical, but output only needs to be uniform 32 bytes.</li>
<li>Probably just <cite>BLAKE2b-256(derivation_path)</cite>, in line with our existing primitives.</li>
</ul>
</li>
<li>Key components diagram: <a id="id15" class="footnote_reference" href="#spec-addrs-keys">2</a></li>
<li>Key components specification: <a id="id16" class="footnote_reference" href="#spec-keys">6</a></li>
<li>Encodings and HRPs: <a id="id17" class="footnote_reference" href="#spec-encoding-addr">12</a> <a id="id18" class="footnote_reference" href="#spec-encoding-ivk">13</a> <a id="id19" class="footnote_reference" href="#spec-encoding-fvk">14</a> <a id="id20" class="footnote_reference" href="#spec-encoding-sk">15</a></li>
<li>HD key derivation specification: <a id="id21" class="footnote_reference" href="#zip-0032">23</a></li>
<li>Design rationale: <a id="id22" class="footnote_reference" href="#design-keys">18</a></li>
</ul>
</section>

10
zip-0224.rst
View File

@ -120,18 +120,14 @@ Keys and addresses are encoded using Bech32. Orchard addresses used with the Zca
have the prefix "zo" (compared to "zc" for Sprout and "zs" for Sapling).
Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt
the Sapling HD mechanism from ZIP 32 [#zip-0032]_ to Orchard; instead, we define a simple
hardened-only derivation mechanism.
the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only
derivation mechanism (similar to Sprout).
- Key components diagram: [#spec-addrs-keys]_
- Key components specification: [#spec-keys]_
- Encodings and HRPs: [#spec-encoding-addr]_ [#spec-encoding-ivk]_ [#spec-encoding-fvk]_
[#spec-encoding-sk]_
- HD key derivation specification: TODO
- Needs to be hierarchical, but output only needs to be uniform 32 bytes.
- Probably just `BLAKE2b-256(derivation_path)`, in line with our existing primitives.
- HD key derivation specification: [#zip-0032]_
- Design rationale: [#design-keys]_
Notes