1161 lines
84 KiB
HTML
1161 lines
84 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<title>ZIP 32: Shielded Hierarchical Deterministic Wallets</title>
|
|
<meta charset="utf-8" />
|
|
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
|
<body>
|
|
<section>
|
|
<pre>ZIP: 32
|
|
Title: Shielded Hierarchical Deterministic Wallets
|
|
Owners: Jack Grigg <str4d@electriccoin.co>
|
|
Daira Hopwood <daira@electriccoin.co>
|
|
Credits: Sean Bowe
|
|
Kris Nuttycombe
|
|
Ying Tong Lai
|
|
Pieter Wuille
|
|
Marek Palatinus
|
|
Pavol Rusnak
|
|
Status: Final
|
|
Category: Standards / Wallet
|
|
Created: 2018-05-22
|
|
License: MIT</pre>
|
|
<p>
|
|
<span class="math">\(% This ZIP makes heavy use of mathematical markup. If you can see this, you may want to instead view the rendered version at https://zips.z.cash/zip-0032 .\)</span>
|
|
</p>
|
|
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
|
<p>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#protocol-jubjub">15</a>.</p>
|
|
<p>A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.</p>
|
|
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">10</a>.</p>
|
|
</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" class="section-anchor" 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="id4" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</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>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>
|
|
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>BIP 32 <a id="id6" class="footnote_reference" href="#bip-0032">2</a> is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses <a id="id7" class="footnote_reference" href="#slip-0044">6</a>) generate keys and addresses deterministically. This has several advantages over random generation:</p>
|
|
<ul>
|
|
<li>Wallets only need to store a single seed (particularly useful for hardware wallets).</li>
|
|
<li>A one-time backup of the seed (usually stored as a word phrase <a id="id8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
|
|
<li>Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.</li>
|
|
<li>Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.</li>
|
|
</ul>
|
|
<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" class="section-anchor" 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 Zcash protocol specification <a id="id9" class="footnote_reference" href="#protocol">9</a>. They are reproduced here for convenience:</p>
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{truncate}_k(S)\)</span>
|
|
means the sequence formed from the first
|
|
<span class="math">\(k\)</span>
|
|
elements of
|
|
<span class="math">\(S\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(a\,||\,b\)</span>
|
|
means the concatenation of sequences
|
|
<span class="math">\(a\)</span>
|
|
then
|
|
<span class="math">\(b\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\([k] P\)</span>
|
|
means scalar multiplication of the elliptic curve point
|
|
<span class="math">\(P\)</span>
|
|
by the scalar
|
|
<span class="math">\(k\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{LEOS2IP}_\ell(S)\)</span>
|
|
is the integer in range
|
|
<span class="math">\(\{ 0\,.\!. 2^\ell - 1 \}\)</span>
|
|
represented in little-endian order by the byte sequence
|
|
<span class="math">\(S\)</span>
|
|
of length
|
|
<span class="math">\(\ell/8\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{I2LEBSP}_\ell(k)\)</span>
|
|
is the sequence of
|
|
<span class="math">\(\ell\)</span>
|
|
bits representing
|
|
<span class="math">\(k\)</span>
|
|
in little-endian order.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{LEBS2OSP}_\ell(B)\)</span>
|
|
is defined as follows when
|
|
<span class="math">\(\ell\)</span>
|
|
is a multiple of
|
|
<span class="math">\(8\)</span>
|
|
: convert each group of 8 bits in
|
|
<span class="math">\(B\)</span>
|
|
to a byte value with the least significant bit first, and concatenate the resulting bytes in the same order as the groups.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
|
|
is the representation of the Jubjub elliptic curve point
|
|
<span class="math">\(P\)</span>
|
|
as a bit sequence, defined in <a id="id10" class="footnote_reference" href="#protocol-jubjub">15</a>.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span>
|
|
refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string
|
|
<span class="math">\(p\)</span>
|
|
, and input
|
|
<span class="math">\(x\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{512}(p, x)\)</span>
|
|
refers to unkeyed BLAKE2b-512 in sequential mode, with an output digest length of 64 bytes, 16-byte personalization string
|
|
<span class="math">\(p\)</span>
|
|
, and input
|
|
<span class="math">\(x\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{PRF^{expand}}(\mathsf{sk}, t) :=\)</span>
|
|
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“Zcash_ExpandSeed”},\)</span>
|
|
<span class="math">\(\mathsf{sk}\,||\,t)\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(r_\mathbb{J}\)</span>
|
|
is the order of the Jubjub large prime subgroup.</li>
|
|
<li>
|
|
<span class="math">\(r_\mathbb{P}\)</span>
|
|
is the order of the Pallas curve.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{ToScalar^{Sapling}}(x) :=\)</span>
|
|
<span class="math">\(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{ToScalar^{Orchard}}(x) :=\)</span>
|
|
<span class="math">\(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{P}}\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}(d)\)</span>
|
|
maps a diversifier
|
|
<span class="math">\(d\)</span>
|
|
to a base point on the Jubjub elliptic curve, or to
|
|
<span class="math">\(\bot\)</span>
|
|
if the diversifier is invalid. It is instantiated in <a id="id11" class="footnote_reference" href="#protocol-concretediversifyhash">13</a>.</li>
|
|
</ul>
|
|
<p>The following algorithm standardized in <a id="id12" class="footnote_reference" href="#nist-sp-800-38g">22</a> is used:</p>
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\)</span>
|
|
refers to the FF1 encryption algorithm using AES with a 256-bit
|
|
<span class="math">\(key\)</span>
|
|
, and parameters
|
|
<span class="math">\(radix = 2,\)</span>
|
|
<span class="math">\(minlen = 88,\)</span>
|
|
<span class="math">\(maxlen = 88\)</span>
|
|
. It will be used only with the empty string
|
|
<span class="math">\(\texttt{“”}\)</span>
|
|
as the
|
|
<span class="math">\(tweak\)</span>
|
|
.
|
|
<span class="math">\(x\)</span>
|
|
is a sequence of 88 bits, as is the output.</li>
|
|
</ul>
|
|
<p>We also define the following conversion function:</p>
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{I2LEOSP}_\ell(k)\)</span>
|
|
is the byte sequence
|
|
<span class="math">\(S\)</span>
|
|
of length
|
|
<span class="math">\(\ell/8\)</span>
|
|
representing in little-endian order the integer
|
|
<span class="math">\(k\)</span>
|
|
in range
|
|
<span class="math">\(\{ 0\,.\!. 2^\ell - 1 \}\)</span>
|
|
. It is the reverse operation of
|
|
<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 and Orchard specifications), which is the opposite of BIP 32.</p>
|
|
<p>We adapt the path notation of BIP 32 <a id="id13" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
|
|
<span class="math">\('\)</span>
|
|
) to indicate hardened derivation (
|
|
<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{CDKfvk}(\mathsf{CDKfvk}(\mathsf{CDKfvk}(m_\mathsf{Sapling}, a), b), c)\)</span>
|
|
is written as
|
|
<span class="math">\(m_\mathsf{Sapling} / a / b / c\)</span>
|
|
.</li>
|
|
</ul>
|
|
</section>
|
|
<section id="specification-sapling-key-derivation"><h2><span class="section-heading">Specification: Sapling key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-sapling-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<section id="sapling-extended-keys"><h3><span class="section-heading">Sapling extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
<p>BIP 32 defines a method to derive a number of child keys from a parent key. In order to prevent these from depending solely on the parent key itself, both the private and public keys are extended with a 32-byte chain code. We similarly extend Sapling keys with a chain code here. However, the concepts of "private" and "public" keys in BIP 32 do not map cleanly to Sapling's key components. We take the following approach:</p>
|
|
<ul>
|
|
<li>We derive child Sapling expanded spending keys, rather than Sapling spending keys. This enables us to implement both hardened and non-hardened derivation modes (the latter being incompatible with Sapling spending keys).</li>
|
|
<li>We do not derive Sapling public keys directly, as this would prevent the use of diversified addresses. Instead, we derive Sapling full viewing keys, from which payment addresses can be generated. This maintains the trust semantics of BIP 32: someone with access to a BIP 32 extended public key is able to view all transactions involving that address, which a Sapling full viewing key also enables.</li>
|
|
</ul>
|
|
<p>We represent a Sapling extended spending key as
|
|
<span class="math">\((\mathsf{ask, nsk, ovk, dk, c})\)</span>
|
|
, where
|
|
<span class="math">\((\mathsf{ask, nsk, ovk})\)</span>
|
|
is the normal Sapling expanded spending key,
|
|
<span class="math">\(\mathsf{dk}\)</span>
|
|
is a diversifier key, and
|
|
<span class="math">\(\mathsf{c}\)</span>
|
|
is the chain code.</p>
|
|
<p>We represent a Sapling extended full viewing key as
|
|
<span class="math">\((\mathsf{ak, nk, ovk, dk, c})\)</span>
|
|
, where
|
|
<span class="math">\((\mathsf{ak, nk, ovk})\)</span>
|
|
is the normal Sapling full viewing key,
|
|
<span class="math">\(\mathsf{dk}\)</span>
|
|
is the same diversifier key as above, and
|
|
<span class="math">\(\mathsf{c}\)</span>
|
|
is the chain code.</p>
|
|
</section>
|
|
<section id="sapling-helper-functions"><h3><span class="section-heading">Sapling helper functions</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-helper-functions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
<p>Define</p>
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk}) :=\)</span>
|
|
<span class="math">\(\mathsf{I2LEOSP}_{256}(\mathsf{ask})\)</span>
|
|
<span class="math">\(||\,\mathsf{I2LEOSP}_{256}(\mathsf{nsk})\)</span>
|
|
<span class="math">\(||\,\mathsf{ovk}\)</span>
|
|
<span class="math">\(||\,\mathsf{dk}\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=\)</span>
|
|
<span class="math">\(\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))\)</span>
|
|
<span class="math">\(||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))\)</span>
|
|
<span class="math">\(||\,\mathsf{ovk}\)</span>
|
|
<span class="math">\(||\,\mathsf{dk}\)</span>
|
|
</li>
|
|
</ul>
|
|
</section>
|
|
<section id="sapling-master-key-generation"><h3><span class="section-heading">Sapling master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-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{“ZcashIP32Sapling”}, 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>
|
|
, and
|
|
<span class="math">\(I_R\)</span>
|
|
as the master chain code
|
|
<span class="math">\(\mathsf{c}_m\)</span>
|
|
.</li>
|
|
<li>Calculate
|
|
<span class="math">\(\mathsf{ask}_m\)</span>
|
|
,
|
|
<span class="math">\(\mathsf{nsk}_m\)</span>
|
|
, and
|
|
<span class="math">\(\mathsf{ovk}_m\)</span>
|
|
via the standard Sapling derivation <a id="id15" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>:
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{ask}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{nsk}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x01}]))\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{ovk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x02}]))\)</span>
|
|
.</li>
|
|
</ul>
|
|
</li>
|
|
<li>Calculate
|
|
<span class="math">\(\mathsf{dk}_m\)</span>
|
|
similarly:
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{dk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x10}]))\)</span>
|
|
.</li>
|
|
</ul>
|
|
</li>
|
|
<li>Return
|
|
<span class="math">\((\mathsf{ask}_m, \mathsf{nsk}_m, \mathsf{ovk}_m, \mathsf{dk}_m, \mathsf{c}_m)\)</span>
|
|
as the master extended spending key
|
|
<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
|
|
<span class="math">\(i\)</span>
|
|
, depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.</p>
|
|
<section id="deriving-a-child-extended-spending-key"><h4><span class="section-heading">Deriving a child extended spending key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-spending-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
|
<p>
|
|
<span class="math">\(\mathsf{CDKsk}((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\)</span>
|
|
<span class="math">\(\rightarrow (\mathsf{ask}_i, \mathsf{nsk}_i, \mathsf{ovk}_i, \mathsf{dk}_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{0x11}]\)</span>
|
|
<span class="math">\(||\,\mathsf{EncodeExtSKParts}(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\)</span>
|
|
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
|
|
.</li>
|
|
<li>If not (normal child): let
|
|
<span class="math">\(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]\)</span>
|
|
<span class="math">\(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\)</span>
|
|
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
|
|
where
|
|
<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="id17" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</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>Let
|
|
<span class="math">\(I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\)</span>
|
|
.</li>
|
|
<li>Return:
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{ask}_i = (I_\mathsf{ask} + \mathsf{ask}_{par}) \pmod{r_\mathbb{J}}\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{nsk}_i = (I_\mathsf{nsk} + \mathsf{nsk}_{par}) \pmod{r_\mathbb{J}}\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]\)</span>
|
|
<span class="math">\(||\,\mathsf{ovk}_{par}))\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]\)</span>
|
|
<span class="math">\(||\,\mathsf{dk}_{par}))\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{c}_i = I_R\)</span>
|
|
.</li>
|
|
</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="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="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>
|
|
</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): return failure.</li>
|
|
<li>If not (normal child): let
|
|
<span class="math">\(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]\)</span>
|
|
<span class="math">\(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\)</span>
|
|
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
|
|
.</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>Let
|
|
<span class="math">\(I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\)</span>
|
|
.</li>
|
|
<li>Return:
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{ak}_i = [I_\mathsf{ask}]\,\mathcal{G}^\mathsf{Sapling} + \mathsf{ak}_{par}\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{nk}_i = [I_\mathsf{nsk}]\,\mathcal{H}^\mathsf{Sapling} + \mathsf{nk}_{par}\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]\)</span>
|
|
<span class="math">\(||\,\mathsf{ovk}_{par}))\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]\)</span>
|
|
<span class="math">\(||\,\mathsf{dk}_{par}))\)</span>
|
|
</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{c}_i = I_R\)</span>
|
|
.</li>
|
|
</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="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>
|
|
be the external spending key.</p>
|
|
<ul>
|
|
<li>Derive the corresponding
|
|
<span class="math">\(\mathsf{ak}\)</span>
|
|
and
|
|
<span class="math">\(\mathsf{nk}\)</span>
|
|
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>
|
|
<li>Let
|
|
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(\mathsf{nsk_{internal}} = (I_\mathsf{nsk} + \mathsf{nsk}) \pmod{r_\mathbb{J}}\)</span>
|
|
.</li>
|
|
<li>Split
|
|
<span class="math">\(R\)</span>
|
|
into two 32-byte sequences,
|
|
<span class="math">\(\mathsf{dk_{internal}}\)</span>
|
|
and
|
|
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
|
|
.</li>
|
|
<li>Return the internal spending key as
|
|
<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="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>
|
|
<ul>
|
|
<li>Let
|
|
<span class="math">\(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(\mathsf{nk_{internal}} = [I_\mathsf{nsk}] \mathcal{H}^\mathsf{Sapling} + \mathsf{nk}\)</span>
|
|
.</li>
|
|
<li>Split
|
|
<span class="math">\(R\)</span>
|
|
into two 32-byte sequences,
|
|
<span class="math">\(\mathsf{dk_{internal}}\)</span>
|
|
and
|
|
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
|
|
.</li>
|
|
<li>Return the internal full viewing key as
|
|
<span class="math">\((\mathsf{ak}, \mathsf{nk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})\)</span>
|
|
.</li>
|
|
</ul>
|
|
<p>This design uses the same technique as non-hardened derivation to obtain a full viewing key with the same spend authority (the private key corresponding to
|
|
<span class="math">\(\mathsf{ak}\)</span>
|
|
) as the original, but viewing authority only for internal transfers.</p>
|
|
<p>The values of
|
|
<span class="math">\(I\)</span>
|
|
,
|
|
<span class="math">\(I_\mathsf{nsk}\)</span>
|
|
, and
|
|
<span class="math">\(R\)</span>
|
|
are the same between deriving a full viewing key, and deriving the corresponding spending key. Both of these derivations are shown in the following diagram:</p>
|
|
<figure class="align-center" align="center">
|
|
<img width="900px" src="zip-0032-sapling-internal-key-derivation.png" />
|
|
<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="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>
|
|
<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>
|
|
<ul>
|
|
<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_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\)</span>
|
|
.</li>
|
|
</ul>
|
|
<p>A valid diversifier
|
|
<span class="math">\(d_j\)</span>
|
|
is one for which
|
|
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}(d_j) \neq \bot\)</span>
|
|
. For a given
|
|
<span class="math">\(\mathsf{dk}\)</span>
|
|
, approximately half of the possible values of
|
|
<span class="math">\(j\)</span>
|
|
yield valid diversifiers.</p>
|
|
<p>The default diversifier for a Sapling extended key is defined to be
|
|
<span class="math">\(d_j\)</span>
|
|
, where
|
|
<span class="math">\(j\)</span>
|
|
is the least nonnegative integer yielding a valid diversifier.</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 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>
|
|
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" 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{“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>
|
|
<li>Return
|
|
<span class="math">\((\mathsf{sk}_m, \mathsf{c}_m)\)</span>
|
|
as the master extended spending key
|
|
<span class="math">\(m_\mathsf{Orchard}\)</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" class="section-anchor" 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>
|
|
<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>
|
|
<p>Let
|
|
<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="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>
|
|
<ul>
|
|
<li>Let
|
|
<span class="math">\(K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(\mathsf{rivk_{internal}} = \mathsf{ToScalar^{Orchard}}(\mathsf{PRF^{expand}}(K, [\mathtt{0x83}] \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{ak}) \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{nk}))\)</span>
|
|
.</li>
|
|
<li>Return
|
|
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk_{internal}})\)</span>
|
|
.</li>
|
|
</ul>
|
|
<p>The result of applying
|
|
<span class="math">\(\mathsf{DeriveInternalFVK^{Orchard}}\)</span>
|
|
to the external full viewing key is the internal full viewing key. The corresponding expanded internal spending key is
|
|
<span class="math">\((\mathsf{ask}, \mathsf{nk}, \mathsf{rivk_{internal}})\)</span>
|
|
,</p>
|
|
<p>Unlike <a href="#sapling-internal-key-derivation">Sapling internal key derivation</a>, we do not base this internal key derivation procedure on non-hardened derivation, which is not defined for Orchard. We can obtain the desired separation of viewing authority by modifying only the
|
|
<span class="math">\(\mathsf{rivk_{internal}}\)</span>
|
|
field relative to the external full viewing key, which results in different
|
|
<span class="math">\(\mathsf{dk_{internal}}\)</span>
|
|
,
|
|
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
|
|
and
|
|
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
|
|
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="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>
|
|
<p>Given an Orchard extended spending key
|
|
<span class="math">\((\mathsf{sk}_i, \mathsf{c}_i)\)</span>
|
|
:</p>
|
|
<ul>
|
|
<li>Let
|
|
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
|
|
be the Orchard full viewing key for
|
|
<span class="math">\(\mathsf{sk}_i\)</span>
|
|
.</li>
|
|
<li>Let
|
|
<span class="math">\(K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
|
|
and let
|
|
<span class="math">\(B = \mathsf{repr}_{\mathbb{P}}(\mathsf{ak})\,||\,\mathsf{I2LEBSP}_{256}(\mathsf{nk})\)</span>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(K, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(B)))\)</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" 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="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>
|
|
<li>
|
|
<span class="math">\(purpose\)</span>
|
|
: a constant set to
|
|
<span class="math">\(32'\)</span>
|
|
(or
|
|
<span class="math">\(\texttt{0x80000020}\)</span>
|
|
) 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="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>
|
|
.</li>
|
|
<li>
|
|
<span class="math">\(account\)</span>
|
|
: numbered from index
|
|
<span class="math">\(0\)</span>
|
|
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>
|
|
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>
|
|
<section id="sapling-key-path"><h3><span class="section-heading">Sapling key path</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-key-path"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
<p>Sapling provides a mechanism to allow the efficient creation of diversified payment addresses with the same spending authority. 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 Sapling 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{Sapling} / purpose' / coin\_type' / account'\)</span>
|
|
.</li>
|
|
</ul>
|
|
<p>Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier as defined above) 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 approximately
|
|
<span class="math">\(2^{87}\)</span>
|
|
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="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>
|
|
.</li>
|
|
</ul>
|
|
<p><cite>zcashd</cite> version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account
|
|
<span class="math">\(\mathtt{0x7FFFFFFF}\)</span>
|
|
, using hardened derivation for
|
|
<span class="math">\(address\_index\)</span>
|
|
.</p>
|
|
</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
|
|
<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 diversified payment addresses for a given account, if they wish to enable users to give 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" class="section-anchor" 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" 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="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>
|
|
.</li>
|
|
</ul>
|
|
<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="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="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>
|
|
.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
<p>A "seed fingerprint" for the master seed
|
|
<span class="math">\(S\)</span>
|
|
of a hierarchical deterministic wallet is given by:</p>
|
|
<ul>
|
|
<li>
|
|
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_HD_Seed_FP”},\)</span>
|
|
<span class="math">\([\mathsf{length}(S)]\,||\,S)\)</span>
|
|
.</li>
|
|
</ul>
|
|
<p>It MAY be used to uniquely identify a particular hierarchical deterministic wallet.</p>
|
|
<p>No corresponding short tag is defined.</p>
|
|
<p>Note: a previous version of this specification did not have the length byte prefixing the seed. The current specification reflects the implementation in <cite>zcashd</cite>.</p>
|
|
</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="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>
|
|
, 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)\)</span>
|
|
<span class="math">\(||\,parent\_fvk\_tag\)</span>
|
|
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i)\)</span>
|
|
<span class="math">\(||\,\mathsf{c}\)</span>
|
|
<span class="math">\(||\,\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk})\)</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-extended-key-main</code> for the production network, or <code>secret-extended-key-test</code> for the test network.</p>
|
|
</section>
|
|
<section id="sapling-extended-full-viewing-keys"><h3><span class="section-heading">Sapling extended full viewing keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-full-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
<p>A Sapling extended full viewing key
|
|
<span class="math">\((\mathsf{ak, nk, ovk, dk, 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)\)</span>
|
|
<span class="math">\(||\,parent\_fvk\_tag\)</span>
|
|
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i)\)</span>
|
|
<span class="math">\(||\,\mathsf{c}\)</span>
|
|
<span class="math">\(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk})\)</span>
|
|
.</li>
|
|
</ul>
|
|
<p>For the master extended full viewing 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>zxviews</code> for the production network, or <code>zxviewtestsapling</code> for the test network.</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>
|
|
, 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 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="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>
|
|
<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
|
|
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{512}\)</span>
|
|
personalization
|
|
<span class="math">\(\texttt{“ZcashIP32_Sprout”}\)</span>
|
|
, formerly specified for derivation of the master key of the Sprout tree;</li>
|
|
<li>the
|
|
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}\)</span>
|
|
personalization
|
|
<span class="math">\(\texttt{“Zcash_Sprout_AFP”}\)</span>
|
|
, formerly specified for generation of Sprout address fingerprints;</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>
|
|
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<ul>
|
|
<li><a href="https://github.com/zcash-hackworks/zip32">https://github.com/zcash-hackworks/zip32</a></li>
|
|
<li><a href="https://github.com/zcash/librustzcash/pull/29">https://github.com/zcash/librustzcash/pull/29</a></li>
|
|
<li><a href="https://github.com/zcash/zcash/pull/3447">https://github.com/zcash/zcash/pull/3447</a></li>
|
|
<li><a href="https://github.com/zcash/zcash/pull/3492">https://github.com/zcash/zcash/pull/3492</a></li>
|
|
</ul>
|
|
</section>
|
|
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<table id="rfc2119" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>1</th>
|
|
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="bip-0032" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>2</th>
|
|
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki">BIP 32: Hierarchical Deterministic Wallets</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="bip-0039" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>3</th>
|
|
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki">BIP 39: Mnemonic code for generating deterministic keys</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="bip-0043" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>4</th>
|
|
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki">BIP 43: Purpose Field for Deterministic Wallets</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="bip-0044" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>5</th>
|
|
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki">BIP 44: Multi-Account Hierarchy for Deterministic Wallets</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="slip-0044" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>6</th>
|
|
<td><a href="https://github.com/satoshilabs/slips/blob/master/slip-0044.md">SLIP 44: Registered coin types for BIP-0044</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="bip-0173" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>7</th>
|
|
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki">BIP 173: Base32 address format for native v0-16 witness outputs</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="zip-0316" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>8</th>
|
|
<td><a href="zip-0316">ZIP 316: Unified Addresses and Unified Viewing Keys</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>9</th>
|
|
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal]</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-networks" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>10</th>
|
|
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2022.2.19. Section 3.12: Mainnet and Testnet</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-saplingkeycomponents" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>11</th>
|
|
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-orchardkeycomponents" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>12</th>
|
|
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-concretediversifyhash" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>13</th>
|
|
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2022.2.19. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-concretespendauthsig" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>14</th>
|
|
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2022.2.19. Section 5.4.6.1: Spend Authorization Signature</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-jubjub" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>15</th>
|
|
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Version 2022.2.19. Section 5.4.9.3: Jubjub</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-sproutpaymentaddrencoding" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>16</th>
|
|
<td><a href="protocol/protocol.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.2.1: Sprout Payment Addresses</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-sproutspendingkeyencoding" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>17</th>
|
|
<td><a href="protocol/protocol.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.2.3: Sprout Spending Keys</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-saplingfullviewingkeyencoding" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>18</th>
|
|
<td><a href="protocol/protocol.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.3: Sapling Full Viewing Keys</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-saplingspendingkeyencoding" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>19</th>
|
|
<td><a href="protocol/protocol.pdf#saplingspendingkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.4: Sapling Spending Keys</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-orchardfullviewingkeyencoding" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>20</th>
|
|
<td><a href="protocol/protocol.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing Keys</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-orchardspendingkeyencoding" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>21</th>
|
|
<td><a href="protocol/protocol.pdf#orchardspendingkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.5: Orchard Spending Keys</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="nist-sp-800-38g" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>22</th>
|
|
<td><a href="https://dx.doi.org/10.6028/NIST.SP.800-38G">NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</section>
|
|
</section>
|
|
</body>
|
|
</html> |