mirror of https://github.com/zcash/zips.git
ZIPs 32 and 316: Regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
df0f9e6bee
commit
8734965d0c
271
zip-0032.html
271
zip-0032.html
|
|
@ -11,7 +11,10 @@
|
|||
Title: Shielded Hierarchical Deterministic Wallets
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Pieter Wuille
|
||||
Credits: Sean Bowe
|
||||
Kris Nuttycombe
|
||||
Ying Tong Lai
|
||||
Pieter Wuille
|
||||
Marek Palatinus
|
||||
Pavol Rusnak
|
||||
Status: Final
|
||||
|
|
@ -23,9 +26,9 @@ License: MIT</pre>
|
|||
</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">13</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">9</a>.</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>
|
||||
|
|
@ -49,7 +52,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" 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">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="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>
|
||||
|
|
@ -101,7 +104,7 @@ License: MIT</pre>
|
|||
<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">13</a>.</li>
|
||||
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
|
||||
|
|
@ -125,18 +128,25 @@ License: MIT</pre>
|
|||
<span class="math">\(r_\mathbb{J}\)</span>
|
||||
is the order of the Jubjub large prime subgroup.</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{ToScalar}(x) :=\)</span>
|
||||
<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{DiversifyHash}(d)\)</span>
|
||||
<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">11</a>.</li>
|
||||
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">20</a> is used:</p>
|
||||
<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>
|
||||
|
|
@ -264,13 +274,13 @@ License: MIT</pre>
|
|||
<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">10</a>:
|
||||
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}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span>
|
||||
<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}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x01}]))\)</span>
|
||||
<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>
|
||||
|
|
@ -320,7 +330,7 @@ License: MIT</pre>
|
|||
<span class="math">\((\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})\)</span>
|
||||
is the full viewing key derived from
|
||||
<span class="math">\((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})\)</span>
|
||||
as described in <a id="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">10</a>.</li>
|
||||
as described in <a id="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Split
|
||||
|
|
@ -331,10 +341,10 @@ License: MIT</pre>
|
|||
<span class="math">\(I_R\)</span>
|
||||
.</li>
|
||||
<li>Let
|
||||
<span class="math">\(I_\mathsf{ask} = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\)</span>
|
||||
<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}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\)</span>
|
||||
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\)</span>
|
||||
.</li>
|
||||
<li>Return:
|
||||
<ul>
|
||||
|
|
@ -361,10 +371,10 @@ License: MIT</pre>
|
|||
</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}\)</span>
|
||||
be as defined in <a id="id17" class="footnote_reference" href="#protocol-concretespendauthsig">12</a> and let
|
||||
<span class="math">\(\mathcal{H}\)</span>
|
||||
be as defined in <a id="id18" class="footnote_reference" href="#protocol-saplingkeycomponents">10</a>.</p>
|
||||
<span class="math">\(\mathcal{G}^\mathsf{Sapling}\)</span>
|
||||
be as defined in <a id="id17" class="footnote_reference" href="#protocol-concretespendauthsig">14</a> and let
|
||||
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
|
||||
be as defined in <a id="id18" 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>
|
||||
|
|
@ -390,18 +400,18 @@ License: MIT</pre>
|
|||
<span class="math">\(I_R\)</span>
|
||||
.</li>
|
||||
<li>Let
|
||||
<span class="math">\(I_\mathsf{ask} = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\)</span>
|
||||
<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}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\)</span>
|
||||
<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{ak}_{par}\)</span>
|
||||
<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{nk}_{par}\)</span>
|
||||
<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>
|
||||
|
|
@ -419,6 +429,91 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="sapling-internal-key-derivation"><h3><span class="section-heading">Sapling internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree <a id="id19" class="footnote_reference" href="#bip-0044">5</a>, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
|
||||
<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="id20" 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>
|
||||
</section>
|
||||
<section id="deriving-a-sapling-internal-full-viewing-key"><h4><span class="section-heading">Deriving a Sapling internal full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-full-viewing-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Let
|
||||
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
|
||||
be as defined in <a id="id21" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
|
||||
<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="id22" class="footnote_reference" href="#zip-0316">8</a>.</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>
|
||||
|
|
@ -436,7 +531,7 @@ License: MIT</pre>
|
|||
<p>A valid diversifier
|
||||
<span class="math">\(d_j\)</span>
|
||||
is one for which
|
||||
<span class="math">\(\mathsf{DiversifyHash}(d_j) \neq \bot\)</span>
|
||||
<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
|
||||
|
|
@ -466,7 +561,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{EncodeASK}(\mathsf{a_{sk}})\)</span>
|
||||
be the 32-byte encoding of
|
||||
<span class="math">\(\mathsf{a_{sk}}\)</span>
|
||||
in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a id="id19" class="footnote_reference" href="#protocol-sproutspendingkeyencoding">15</a>.</p>
|
||||
in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a id="id23" class="footnote_reference" href="#protocol-sproutspendingkeyencoding">17</a>.</p>
|
||||
<p>Let
|
||||
<span class="math">\(\mathsf{DecodeASK}(ASK)\)</span>
|
||||
be the result of clearing the 4 most significant bits of the first byte of
|
||||
|
|
@ -538,6 +633,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{c}_i\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>There is no support for internal key derivation for Sprout.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="specification-orchard-key-derivation"><h2><span class="section-heading">Specification: Orchard key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-orchard-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -618,6 +714,41 @@ License: MIT</pre>
|
|||
.</li>
|
||||
</ul>
|
||||
</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="id24" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</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>
|
||||
</ul>
|
||||
<p>Then the expanded internal spending key is
|
||||
<span class="math">\((\mathsf{ask}, \mathsf{nk}, \mathsf{rivk_{internal}})\)</span>
|
||||
, and the internal full viewing key is
|
||||
<span class="math">\((\mathsf{ak}, \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="id25" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
|
||||
<figure class="align-center" align="center">
|
||||
<img width="720px" src="zip-0032-orchard-internal-key-derivation.png" />
|
||||
<figcaption>Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key</figcaption>
|
||||
</figure>
|
||||
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id26" class="footnote_reference" href="#zip-0316">8</a>.</p>
|
||||
</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
|
||||
|
|
@ -630,12 +761,12 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{sk}_i\)</span>
|
||||
.</li>
|
||||
<li>Let
|
||||
<span class="math">\(\mathsf{K} = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
|
||||
<span class="math">\(K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
|
||||
and let
|
||||
<span class="math">\(\mathsf{B} = \mathsf{repr}_{\mathbb{P}}(\mathsf{ak})\,||\,\mathsf{I2LEBSP}_{256}(\mathsf{nk})\)</span>
|
||||
<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}}(\mathsf{K}, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(\mathsf{B})))\)</span>
|
||||
<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>
|
||||
|
|
@ -657,7 +788,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a rel="bookmark" href="#specification-wallet-usage"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id20" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
|
||||
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id27" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
|
||||
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a rel="bookmark" href="#key-path-levels"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
|
||||
<ul>
|
||||
|
|
@ -670,7 +801,7 @@ License: MIT</pre>
|
|||
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.</li>
|
||||
<li>
|
||||
<span class="math">\(coin\_type\)</span>
|
||||
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id21" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
|
||||
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id28" 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>
|
||||
|
|
@ -679,7 +810,7 @@ License: MIT</pre>
|
|||
<span class="math">\(account\)</span>
|
||||
: numbered from index
|
||||
<span class="math">\(0\)</span>
|
||||
in sequentially increasing manner. Defined as in BIP 44 <a id="id22" class="footnote_reference" href="#bip-0044">5</a>.</li>
|
||||
in sequentially increasing manner. Defined as in BIP 44 <a id="id29" 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>
|
||||
|
|
@ -701,7 +832,7 @@ License: MIT</pre>
|
|||
payment addresses, because each diversifier has around a 50% chance of being invalid.</p>
|
||||
<p>If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened
|
||||
<span class="math">\(address\_index\)</span>
|
||||
path level as in <a id="id23" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
path level as in <a id="id30" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
|
||||
|
|
@ -741,7 +872,7 @@ License: MIT</pre>
|
|||
<section id="sapling-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Sapling Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
|
||||
<span class="math">\(\mathit{FVK}\)</span>
|
||||
(as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">16</a>) is given by:</p>
|
||||
(as specified in <a id="id31" 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>
|
||||
|
|
@ -753,7 +884,7 @@ License: MIT</pre>
|
|||
<section id="sprout-address-fingerprints-and-tags"><h3><span class="section-heading">Sprout Address Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-address-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding
|
||||
<span class="math">\(\mathit{ADDR}\)</span>
|
||||
(as specified in <a id="id25" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">14</a>, including the lead bytes) is given by:</p>
|
||||
(as specified in <a id="id32" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">16</a>, including the lead bytes) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, \mathit{ADDR})\)</span>
|
||||
|
|
@ -765,7 +896,7 @@ License: MIT</pre>
|
|||
<section id="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding
|
||||
<span class="math">\(\mathit{FVK}\)</span>
|
||||
(as specified in <a id="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">18</a>) is given by:</p>
|
||||
(as specified in <a id="id33" 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>
|
||||
|
|
@ -790,7 +921,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="specification-key-encodings"><h2><span class="section-heading">Specification: Key Encodings</span><span class="section-anchor"> <a rel="bookmark" href="#specification-key-encodings"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id27" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
|
||||
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id34" 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>
|
||||
|
|
@ -914,7 +1045,7 @@ License: MIT</pre>
|
|||
<span class="math">\(0\)</span>
|
||||
.</p>
|
||||
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-orchard-extsk-main</code> for Mainnet, or <code>secret-orchard-extsk-test</code> for Testnet.</p>
|
||||
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id28" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">19</a>.</p>
|
||||
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id35" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -985,106 +1116,122 @@ License: MIT</pre>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol" class="footnote">
|
||||
<table id="zip-0316" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]</a></td>
|
||||
<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>9</th>
|
||||
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet</a></td>
|
||||
<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>10</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.2: Sapling Key Components</a></td>
|
||||
<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>11</th>
|
||||
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
|
||||
<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>12</th>
|
||||
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature</a></td>
|
||||
<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>13</th>
|
||||
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub</a></td>
|
||||
<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>14</th>
|
||||
<td><a href="protocol/protocol.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.1: Sprout Payment Addresses</a></td>
|
||||
<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>15</th>
|
||||
<td><a href="protocol/protocol.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys</a></td>
|
||||
<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>16</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys</a></td>
|
||||
<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>17</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingspendingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys</a></td>
|
||||
<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>18</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys</a></td>
|
||||
<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>19</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardspendingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys</a></td>
|
||||
<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>20</th>
|
||||
<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>
|
||||
|
|
|
|||
247
zip-0316.html
247
zip-0316.html
|
|
@ -74,8 +74,8 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>Sprout Addresses</li>
|
||||
<li>Sapling Addresses</li>
|
||||
</ul>
|
||||
<p>Each of these has its own Address Encodings, as a string and as a QR code. (Since the QR code is derivable from the string encoding, for many purposes it suffices to consider the string encoding.)</p>
|
||||
<p>The Orchard proposal <a id="id3" class="footnote_reference" href="#zip-0224">18</a> adds a new Address type, Orchard Addresses.</p>
|
||||
<p>Each of these has its own Address Encodings, as a string and as a QR code. (Since the QR code is derivable from the string encoding as described in <a id="id3" class="footnote_reference" href="#protocol-addressandkeyencoding">8</a>, for many purposes it suffices to consider the string encoding.)</p>
|
||||
<p>The Orchard proposal <a id="id4" class="footnote_reference" href="#zip-0224">24</a> adds a new Address type, Orchard Addresses.</p>
|
||||
<p>The difficulty with defining new Address Encodings for each Address type, is that end-users are forced to be aware of the various types, and in particular which types are supported by a given Consumer or Recipient. In order to make sure that transfers are completed successfully, users may be forced to explicitly generate Addresses of different types and re-distribute encodings of them, which adds significant friction and cognitive overhead to understanding and using Zcash.</p>
|
||||
<p>The goals for a Unified Address standard are as follows:</p>
|
||||
<ul>
|
||||
|
|
@ -95,7 +95,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<section id="overview"><h3><span class="section-heading">Overview</span><span class="section-anchor"> <a rel="bookmark" href="#overview"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Unified Addresses specify multiple methods for payment to a Recipient's Wallet. The Sender's Wallet can then non-interactively select the method of payment.</p>
|
||||
<p>Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="id4" class="footnote_reference" href="#zip-0321">19</a> and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="id5" class="footnote_reference" href="#zip-0321">26</a> and similar schemes. Since Payment Requests encode addresses as alphanumeric strings, no change to ZIP 321 is required in order to use Unified Addresses in Payment Requests.</p>
|
||||
</section>
|
||||
<section id="concepts"><h3><span class="section-heading">Concepts</span><span class="section-anchor"> <a rel="bookmark" href="#concepts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Wallets follow a model <em>Interaction Flow</em> as follows:</p>
|
||||
|
|
@ -123,7 +123,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<p>The string encoding is resilient against typos, transcription errors, cut-and-paste errors, unanticipated truncation, or other anticipated UX hazards.</p>
|
||||
<p>There is a well-defined encoding of a Unified Address (or UFVK or UIVK) as a QR Code, which produces QR codes that are reasonably compact and robust.</p>
|
||||
<p>There is a well-defined transformation between the QR Code and string encodings in either direction.</p>
|
||||
<p>The string encoding fits into ZIP-321 Payment URIs <a id="id5" class="footnote_reference" href="#zip-0321">19</a> and general URIs without introducing parse ambiguities.</p>
|
||||
<p>The string encoding fits into ZIP-321 Payment URIs <a id="id6" class="footnote_reference" href="#zip-0321">26</a> and general URIs without introducing parse ambiguities.</p>
|
||||
<p>The encoding must support sufficiently many Recipient Types to allow for reasonable future expansion.</p>
|
||||
<p>The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them.</p>
|
||||
</section>
|
||||
|
|
@ -140,8 +140,8 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<p>Unified Addresses and Unified Viewing Keys must be able to include Receivers and Viewing Keys of experimental types, possibly alongside non-experimental ones. These experimental Receivers or Viewing Keys must be used only by wallets whose users have explicitly opted into the corresponding experiment.</p>
|
||||
</section>
|
||||
<section id="viewing-keys"><h3><span class="section-heading">Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Unified Full Viewing Key (resp. Unified Incoming Viewing Key) can be used in a similar way to a Full Viewing Key (resp. Incoming Viewing Key) as described in the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
|
||||
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="id7" class="footnote_reference" href="#bip-0032">20</a> and BIP 44 <a id="id8" class="footnote_reference" href="#bip-0044">23</a>, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.</p>
|
||||
<p>A Unified Full Viewing Key (resp. Unified Incoming Viewing Key) can be used in a similar way to a Full Viewing Key (resp. Incoming Viewing Key) as described in the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
|
||||
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="id8" class="footnote_reference" href="#bip-0032">27</a> and BIP 44 <a id="id9" class="footnote_reference" href="#bip-0044">30</a>, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.</p>
|
||||
<p>A wallet should support deriving a UIVK from a UFVK, and a Unified Address from a UIVK.</p>
|
||||
</section>
|
||||
<section id="open-issues-and-known-concerns"><h3><span class="section-heading">Open Issues and Known Concerns</span><span class="section-anchor"> <a rel="bookmark" href="#open-issues-and-known-concerns"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -155,10 +155,10 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<ul>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x03}\)</span>
|
||||
— an Orchard raw address as defined in <a id="id9" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">7</a>;</li>
|
||||
— an Orchard raw address as defined in <a id="id10" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">10</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
— a Sapling raw address as defined in <a id="id10" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">6</a>;</li>
|
||||
— a Sapling raw address as defined in <a id="id11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">9</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
— a Transparent P2SH address, <em>or</em> Typecode
|
||||
|
|
@ -194,12 +194,12 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</p>
|
||||
<p>A Receiver Encoding is the raw encoding of a Shielded Payment Address, or the
|
||||
<span class="math">\(160\!\)</span>
|
||||
-bit script hash of a P2SH address <a id="id11" class="footnote_reference" href="#p2sh">27</a>, or the
|
||||
-bit script hash of a P2SH address <a id="id12" class="footnote_reference" href="#p2sh">35</a>, or the
|
||||
<span class="math">\(160\!\)</span>
|
||||
-bit validating key hash of a P2PKH address <a id="id12" class="footnote_reference" href="#p2pkh">26</a>.</p>
|
||||
-bit validating key hash of a P2PKH address <a id="id13" class="footnote_reference" href="#p2pkh">34</a>.</p>
|
||||
<p>Let <code>padding</code> be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append <code>padding</code> to the concatenated encodings, and then apply the
|
||||
<span class="math">\(\mathsf{F4Jumble}\)</span>
|
||||
algorithm as described in <a href="#jumbling">Jumbling</a>. The output is then encoded with Bech32m <a id="id13" class="footnote_reference" href="#bip-0350">25</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
algorithm as described in <a href="#jumbling">Jumbling</a>. The output is then encoded with Bech32m <a id="id14" class="footnote_reference" href="#bip-0350">33</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
<p>To decode a Unified Address Encoding, a Consumer MUST use the following procedure:</p>
|
||||
<ul>
|
||||
<li>Decode using Bech32m, rejecting any address with an incorrect checksum.</li>
|
||||
|
|
@ -209,7 +209,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>Let <code>padding</code> be the Human-Readable Part, padded to 16 bytes as for encoding. If the result ends in <code>padding</code>, remove these 16 bytes; otherwise reject.</li>
|
||||
<li>Parse the result as a raw encoding as described above, rejecting the entire Unified Address if it does not parse correctly.</li>
|
||||
</ul>
|
||||
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id14" class="footnote_reference" href="#bip-0350">25</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
|
||||
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id15" class="footnote_reference" href="#bip-0350">33</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
|
||||
<p>A wallet MAY allow its user(s) to configure which Receiver Types it can send to. It MUST NOT allow the user(s) to change the order of the Priority List used to choose the Receiver Type, except by opting into experiments.</p>
|
||||
</section>
|
||||
<section id="encoding-of-unified-full-incoming-viewing-keys"><h3><span class="section-heading">Encoding of Unified Full/Incoming Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-full-incoming-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -230,7 +230,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)</span>
|
||||
, where
|
||||
<span class="math">\(\mathsf{EncodeExtFVKParts}\)</span>
|
||||
is defined in <a id="id15" class="footnote_reference" href="#zip-0032-sapling-helper-functions">11</a>. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.</li>
|
||||
is defined in <a id="id16" class="footnote_reference" href="#zip-0032-sapling-helper-functions">14</a>. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.</li>
|
||||
<li>A Sapling IVK Encoding, also with Typecode
|
||||
<span class="math">\(\mathtt{0x02},\)</span>
|
||||
is an encoding of
|
||||
|
|
@ -241,19 +241,19 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be diversified in an unlinkable way). The Typecode
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
MUST NOT be included in a UFVK or UIVK by Producers, and MUST be treated as unrecognized by Consumers.</li>
|
||||
<li>For Transparent P2PKH Addresses that are derived according to BIP 32 <a id="id16" class="footnote_reference" href="#bip-0032">20</a> and BIP 44 <a id="id17" class="footnote_reference" href="#bip-0044">23</a>, the FVK and IVK Encodings have Typecode
|
||||
<li>For Transparent P2PKH Addresses that are derived according to BIP 32 <a id="id17" class="footnote_reference" href="#bip-0032">27</a> and BIP 44 <a id="id18" class="footnote_reference" href="#bip-0044">30</a>, the FVK and IVK Encodings have Typecode
|
||||
<span class="math">\(\mathtt{0x00}.\)</span>
|
||||
Both of these are encodings of the chain code and public key
|
||||
<span class="math">\((\mathsf{c}, \mathsf{pk})\)</span>
|
||||
given by
|
||||
<span class="math">\(\mathsf{c}\,||\,\mathsf{ser_P}(\mathsf{pk})\)</span>
|
||||
. (This is the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 <a id="id18" class="footnote_reference" href="#bip-0032-serialization-format">21</a>.) However, the FVK uses the key at the Account level, i.e. at path
|
||||
. (This is the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 <a id="id19" class="footnote_reference" href="#bip-0032-serialization-format">28</a>.) However, the FVK uses the key at the Account level, i.e. at path
|
||||
<span class="math">\(m / 44' / coin\_type' / account'\)</span>
|
||||
, while the IVK uses the external (non-change) child key at the Change level, i.e. at path
|
||||
<span class="math">\(m / 44' / coin\_type' / account' / 0\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>The Human-Readable Parts (as defined in <a id="id19" class="footnote_reference" href="#bip-0350">25</a>) of Unified Viewing Keys are defined as follows:</p>
|
||||
<p>The Human-Readable Parts (as defined in <a id="id20" class="footnote_reference" href="#bip-0350">33</a>) of Unified Viewing Keys are defined as follows:</p>
|
||||
<ul>
|
||||
<li>“<code>uivk</code>” for Unified Incoming Viewing Keys on Mainnet;</li>
|
||||
<li>“<code>uivktest</code>” for Unified Incoming Viewing Keys on Testnet;</li>
|
||||
|
|
@ -278,13 +278,13 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathtt{length}\)</span>
|
||||
fields are encoded as
|
||||
<span class="math">\(\mathtt{compactSize}.\)</span>
|
||||
<a id="id20" class="footnote_reference" href="#bitcoin-compactsize">28</a> (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.)</li>
|
||||
<a id="id21" class="footnote_reference" href="#bitcoin-compactsize">36</a> (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.)</li>
|
||||
<li>Within a single UA or UVK, all HD-derived Receivers, FVKs, and IVKs SHOULD represent an Address or Viewing Key for the same account (as used in the ZIP 32 or BIP 44 Account level).</li>
|
||||
<li>For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding.</li>
|
||||
<li>There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade <a id="id21" class="footnote_reference" href="#zip-0211">17</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade <a id="id22" class="footnote_reference" href="#zip-0211">23</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>Consumers MUST ignore constituent Items with Typecodes they do not recognize.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the same Typecode appears more than once, or that include both P2SH and P2PKH Transparent Addresses, or that contain only a Transparent Address.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification <a id="id22" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification <a id="id23" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the constituent Items are not ordered in ascending Typecode order. Note that this is different to priority order, and does not affect which Receiver in a Unified Address should be used by a Sender.</li>
|
||||
<li>There MUST NOT be additional bytes at the end of the raw encoding that cannot be interpreted as specified above.</li>
|
||||
</ul>
|
||||
|
|
@ -293,7 +293,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</section>
|
||||
</section>
|
||||
<section id="adding-new-types"><h3><span class="section-heading">Adding new types</span><span class="section-anchor"> <a rel="bookmark" href="#adding-new-types"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id23" class="footnote_reference" href="#zip-0000">10</a>.</p>
|
||||
<p>It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id24" class="footnote_reference" href="#zip-0000">13</a>.</p>
|
||||
<p>For experimentation prior to proposing a ZIP, experimental types MAY be added using the reserved Typecodes
|
||||
<span class="math">\(\mathtt{0xFFFA}\)</span>
|
||||
to
|
||||
|
|
@ -308,16 +308,68 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathtt{0xFC}\)</span>
|
||||
inclusive are reserved to indicate Metadata Items other than Receivers or Viewing Keys. These items MAY affect the overall interpretation of the UA / UVK (for example, by specifying an expiration date).</p>
|
||||
<p>Since Metadata Items are not Receivers, they MUST NOT be selected by a Sender when choosing a Receiver to send to, and since they are not Viewing Keys, they MUST NOT provide additional authority to view information about transactions.</p>
|
||||
<p>Currently no Metadata Types are defined. New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id24" class="footnote_reference" href="#zip-0000">10</a>.</p>
|
||||
<p>Currently no Metadata Types are defined. New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id25" class="footnote_reference" href="#zip-0000">13</a>.</p>
|
||||
</section>
|
||||
<section id="deriving-internal-keys"><h3><span class="section-heading">Deriving Internal Keys</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-internal-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>In addition to external addresses suitable for giving out to Senders, a wallet typically requires addresses for internal operations such as change and auto-shielding.</p>
|
||||
<p>We desire the following properties for viewing authority of both shielded and transparent key trees:</p>
|
||||
<ul>
|
||||
<li>A holder of an FVK can derive external and internal IVKs, and external and internal
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
components.</li>
|
||||
<li>A holder of the external IVK cannot derive the internal IVK, or any of the
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
components.</li>
|
||||
<li>A holder of the external
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
component cannot derive the internal
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
component, or any of the IVKs.</li>
|
||||
</ul>
|
||||
<p>For shielded keys, these properties are achieved by the one-wayness of
|
||||
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
|
||||
and of
|
||||
<span class="math">\(\mathsf{CRH^{ivk}}\)</span>
|
||||
or
|
||||
<span class="math">\(\mathsf{Commit^{ivk}}\)</span>
|
||||
(for Sapling and Orchard respectively). Derivation of an internal shielded FVK from an external shielded FVK is specified in the "Sapling internal key derivation" <a id="id26" class="footnote_reference" href="#zip-0032-sapling-internal-key-derivation">17</a> and "Orchard internal key derivation" <a id="id27" class="footnote_reference" href="#zip-0032-orchard-internal-key-derivation">19</a> sections of ZIP 32.</p>
|
||||
<p>To satisfy the above properties for transparent (P2PKH) keys, we derive the external and internal
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
components from the transparent FVK
|
||||
<span class="math">\((\mathsf{c}, \mathsf{pk})\)</span>
|
||||
(described in <a href="#encoding-of-unified-full-incoming-viewing-keys">Encoding of Unified Full/Incoming Viewing Keys</a>) as follows:</p>
|
||||
<ul>
|
||||
<li>Let
|
||||
<span class="math">\(I_\mathsf{ovk} = \mathsf{PRF^{expand}}_{\mathsf{LEOS2BSP}_{256}(\mathsf{c})}\big([\mathtt{0xd0}] \,||\, \mathsf{ser_P}(\mathsf{pk})\big)\)</span>
|
||||
where
|
||||
<span class="math">\(\mathsf{ser_P}(pk)\)</span>
|
||||
is
|
||||
<span class="math">\(33\)</span>
|
||||
bytes, as specified in <a id="id28" class="footnote_reference" href="#bip-0032-serialization-format">28</a>.</li>
|
||||
<li>Let
|
||||
<span class="math">\(\mathsf{ovk_{external}}\)</span>
|
||||
be the first
|
||||
<span class="math">\(32\)</span>
|
||||
bytes of
|
||||
<span class="math">\(I_\mathsf{ovk}\)</span>
|
||||
and let
|
||||
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
|
||||
be the remaining
|
||||
<span class="math">\(32\)</span>
|
||||
bytes of
|
||||
<span class="math">\(I_\mathsf{ovk}\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>Since an external P2PKH FVK encodes the chain code and public key at the Account level, we can derive both external and internal child keys from it, as described in BIP 44 <a id="id29" class="footnote_reference" href="#bip-0044-path-change">31</a>. It is possible to derive an internal P2PKH FVK from the external P2PKH FVK (i.e. its parent) without having the external spending key, because child derivation at the Change level is non-hardened.</p>
|
||||
</section>
|
||||
<section id="deriving-a-uivk-from-a-ufvk"><h3><span class="section-heading">Deriving a UIVK from a UFVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-uivk-from-a-ufvk"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The following derivations are applied to each component FVK:</p>
|
||||
<ul>
|
||||
<li>For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in <a id="id25" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard FVK, the corresponding Orchard IVK is obtained as specified in <a id="id26" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in <a id="id30" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard FVK, the corresponding Orchard IVK is obtained as specified in <a id="id31" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK is obtained by deriving the child key with non-hardened index
|
||||
<span class="math">\(0\)</span>
|
||||
as described in <a id="id27" class="footnote_reference" href="#bip-0032-public-to-public">22</a>.</li>
|
||||
as described in <a id="id32" class="footnote_reference" href="#bip-0032-public-to-public">29</a>.</li>
|
||||
</ul>
|
||||
<p>In each case, the Typecode remains the same as in the FVK.</p>
|
||||
<p>Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a UIVK from a UFVK.</p>
|
||||
|
|
@ -325,7 +377,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<section id="deriving-a-unified-address-from-a-uivk"><h3><span class="section-heading">Deriving a Unified Address from a UIVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-unified-address-from-a-uivk"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>To derive a Unified Address from a UIVK we need to choose a diversifier index, which MUST be valid for all of the Viewing Key Types in the UIVK. That is,</p>
|
||||
<ul>
|
||||
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="id28" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">13</a>.</li>
|
||||
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="id33" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">16</a>.</li>
|
||||
<li>A Transparent diversifier index MUST be in the range
|
||||
<span class="math">\(0\)</span>
|
||||
to
|
||||
|
|
@ -335,15 +387,28 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</ul>
|
||||
<p>The following derivations are applied to each component IVK using the diversifier index:</p>
|
||||
<ul>
|
||||
<li>For a Sapling IVK, the corresponding Sapling Receiver is obtained as specified in <a id="id29" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard IVK, the corresponding Orchard Receiver is obtained as specified in <a id="id30" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level <a id="id31" class="footnote_reference" href="#bip-0044-path-index">24</a> to derive the corresponding Transparant P2PKH Receiver. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation <a id="id32" class="footnote_reference" href="#bip-0032-public-to-public">22</a> MUST be used. The IVK is assumed to correspond to the extended public key for the non-change element of the path. That is, if the UIVK was constructed correctly then the BIP 44 path of the Transparent P2PKH Receiver will be
|
||||
<li>For a Sapling IVK, the corresponding Sapling Receiver is obtained as specified in <a id="id34" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard IVK, the corresponding Orchard Receiver is obtained as specified in <a id="id35" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level <a id="id36" class="footnote_reference" href="#bip-0044-path-index">32</a> to derive the corresponding Transparent P2PKH Receiver. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation <a id="id37" class="footnote_reference" href="#bip-0032-public-to-public">29</a> MUST be used. The IVK is assumed to correspond to the extended public key for the external (non-change) element of the path. That is, if the UIVK was constructed correctly then the BIP 44 path of the Transparent P2PKH Receiver will be
|
||||
<span class="math">\(m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.\)</span>
|
||||
</li>
|
||||
</ul>
|
||||
<p>In each case, the Typecode remains the same as in the IVK.</p>
|
||||
<p>Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a Receiver from a UIVK.</p>
|
||||
</section>
|
||||
<section id="usage-of-outgoing-viewing-keys"><h3><span class="section-heading">Usage of Outgoing Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#usage-of-outgoing-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When a Sender constructs a transaction that creates Sapling or Orchard notes, it uses an outgoing viewing key, as described in <a id="id38" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="id39" class="footnote_reference" href="#protocol-orchardsend">7</a>, to encrypt an outgoing ciphertext. Decryption with the outgoing viewing key allows recovering the sent note plaintext, including destination address, amount, and memo. The intention is that this outgoing viewing key should be associated with the source of the funds.</p>
|
||||
<p>However, the specification of which outgoing viewing key should be used is left somewhat open in <a id="id40" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="id41" class="footnote_reference" href="#protocol-orchardsend">7</a>; in particular, it was unclear whether transfers should be considered as being sent from an address, or from a ZIP 32 account <a id="id42" class="footnote_reference" href="#zip-0032-key-path-levels">20</a>. The adoption of multiple shielded protocols that support outgoing viewing keys (i.e. Sapling and Orchard) further complicates this question, since from NU5 activation, nothing at the consensus level prevents a wallet from spending both Sapling and Orchard notes in the same transaction. (Recommendations about wallet usage of multiple pools will be given in ZIP 315 <a id="id43" class="footnote_reference" href="#zip-0315">25</a>.)</p>
|
||||
<p>Here we refine the protocol specification in order to allow more precise determination of viewing authority for UFVKs.</p>
|
||||
<p>A Sender will attempt to determine a "sending Account" for each transfer. The preferred approach is for the API used to perform a transfer to directly specify a sending Account. Otherwise, if the Sender can ascertain that all funds used in the transfer are from addresses associated with some Account, then it SHOULD treat that as the sending Account. If not, then the sending Account is undetermined.</p>
|
||||
<p>The Sender also determines a "sending protocol" —one of "transparent", "Sapling", or "Orchard"— corresponding to the most preferred Receiver Type (as given in <a href="#encoding-of-unified-addresses">Encoding of Unified Addresses</a>) of any funds sent in the transaction.</p>
|
||||
<p>If the sending Account has been determined, then the Sender SHOULD use the external or internal
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
(according to the type of transfer), as specified by the sending protocol, of the full viewing key for that Account (i.e. at the ZIP 32 Account level).</p>
|
||||
<p>If the sending Account is undetermined, then the Sender SHOULD choose one of the addresses from which funds are being sent (for example, the first one specified), and then use the external or internal
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
(according to the type of transfer), as specified by the sending protocol, of the full viewing key for that address.</p>
|
||||
</section>
|
||||
<section id="jumbling"><h3><span class="section-heading">Jumbling</span><span class="section-anchor"> <a rel="bookmark" href="#jumbling"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Security goal (<strong>near second preimage resistance</strong>):</p>
|
||||
<ul>
|
||||
|
|
@ -655,7 +720,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.2.16 or later [NU5 proposal]</a></td>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -663,7 +728,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf#notation">Zcash Protocol Specification, Version 2020.2.16. Section 2: Notation</a></td>
|
||||
<td><a href="protocol/protocol.pdf#notation">Zcash Protocol Specification, Version 2022.2.19. Section 2: Notation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -671,7 +736,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2020.2.16. Section 4.2.2: Sapling Key Components</a></td>
|
||||
<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>
|
||||
|
|
@ -679,46 +744,70 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2020.2.16. Section 4.2.3: Orchard Key Components</a></td>
|
||||
<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-saplingsend" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2022.2.19. Section 4.7.2: Sending Notes (Sapling)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardsend" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardsend">Zcash Protocol Specification, Version 2022.2.19. Section 4.7.3: Sending Notes (Orchard)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-addressandkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf#addressandkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6: Encodings of Addresses and Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2020.2.16. Section 5.6.3.1: Sapling Payment Addresses</a></td>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.1: Sapling Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.2: Orchard Raw Payment Addresses</a></td>
|
||||
<th>10</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.2: Orchard Raw Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardinviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys</a></td>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardfullviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.4: Orchard Raw Full Viewing Keys</a></td>
|
||||
<th>12</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="zip-0000" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<th>13</th>
|
||||
<td><a href="zip-0000">ZIP 0: ZIP Process</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -726,7 +815,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-helper-functions" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<th>14</th>
|
||||
<td><a href="zip-0032#sapling-helper-functions">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -734,7 +823,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-extfvk" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<th>15</th>
|
||||
<td><a href="zip-0032#sapling-extended-full-viewing-keys">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -742,23 +831,47 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-diversifier-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<th>16</th>
|
||||
<td><a href="zip-0032#sapling-diversifier-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-sapling-internal-key-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>17</th>
|
||||
<td><a href="zip-0032#sapling-internal-key-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling internal key derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-orchard-child-key-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<th>18</th>
|
||||
<td><a href="zip-0032#orchard-child-key-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-orchard-internal-key-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>19</th>
|
||||
<td><a href="zip-0032#orchard-internal-key-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard internal key derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-key-path-levels" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>20</th>
|
||||
<td><a href="zip-0032#key-path-levels">ZIP 32: Shielded Hierarchical Deterministic Wallets — Key path levels</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-sapling-key-path" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<th>21</th>
|
||||
<td><a href="zip-0032#sapling-key-path">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -766,7 +879,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-orchard-key-path" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<th>22</th>
|
||||
<td><a href="zip-0032#orchard-key-path">ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -774,7 +887,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0211" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>17</th>
|
||||
<th>23</th>
|
||||
<td><a href="zip-0211">ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -782,15 +895,23 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0224" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>18</th>
|
||||
<th>24</th>
|
||||
<td><a href="zip-0224">ZIP 224: Orchard Shielded Protocol</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0315" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>25</th>
|
||||
<td><a href="zip-0315">ZIP 315: Best Practices for Wallet Handling of Multiple Pools</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0321" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>19</th>
|
||||
<th>26</th>
|
||||
<td><a href="zip-0321">ZIP 321: Payment Request URIs</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -798,7 +919,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0032" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>20</th>
|
||||
<th>27</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki">BIP 32: Hierarchical Deterministic Wallets</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -806,7 +927,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0032-serialization-format" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>21</th>
|
||||
<th>28</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format">BIP 32: Hierarchical Deterministic Wallets — Serialization Format</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -814,7 +935,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0032-public-to-public" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>22</th>
|
||||
<th>29</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#public-parent-key--public-child-key">BIP 32: Hierarchical Deterministic Wallets — Child key derivation (CKD) functions: Public parent key → public child key</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -822,15 +943,23 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0044" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>23</th>
|
||||
<th>30</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="bip-0044-path-change" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>31</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#change">BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Change</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0044-path-index" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>24</th>
|
||||
<th>32</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#index">BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Index</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -838,7 +967,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0350" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>25</th>
|
||||
<th>33</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki">BIP 350: Bech32m format for v1+ witness addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -846,7 +975,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="p2pkh" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>26</th>
|
||||
<th>34</th>
|
||||
<td><a href="https://developer.bitcoin.org/devguide/transactions.html#p2pkh-script-validation">Transactions: P2PKH Script Validation — Bitcoin Developer Guide</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -854,7 +983,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="p2sh" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>27</th>
|
||||
<th>35</th>
|
||||
<td><a href="https://developer.bitcoin.org/devguide/transactions.html#pay-to-script-hash-p2sh">Transactions: P2SH Scripts — Bitcoin Developer Guide</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -862,7 +991,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bitcoin-compactsize" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>28</th>
|
||||
<th>36</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer">Variable length integer. Bitcoin Wiki</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
Loading…
Reference in New Issue