mirror of https://github.com/zcash/zips.git
ZIP 32: Address Orchard review comments
This commit is contained in:
Jack Grigg
Daira Hopwood
parent
9cae4aeedc
commit
dd8b82f567
|
|
@ -134,7 +134,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\bot\)</span>
|
||||
if the diversifier is invalid. It is instantiated in <a id="id10" class="footnote_reference" href="#protocol-concretediversifyhash">10</a>.</li>
|
||||
</ul>
|
||||
<p>The following algorithm standardized in <a id="id11" class="footnote_reference" href="#nist-sp-800-38g">16</a> is used:</p>
|
||||
<p>The following algorithm standardized in <a id="id11" class="footnote_reference" href="#nist-sp-800-38g">18</a> is used:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\)</span>
|
||||
|
|
@ -574,6 +574,11 @@ License: MIT</pre>
|
|||
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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -618,12 +623,12 @@ License: MIT</pre>
|
|||
:</p>
|
||||
<ul>
|
||||
<li>Let
|
||||
<span class="math">\(\mathsf{fvk}_i\)</span>
|
||||
<span class="math">\(\mathit{FVK}_i\)</span>
|
||||
be the raw encoding of the Orchard full viewing key for
|
||||
<span class="math">\(\mathsf{sk}_i\)</span>
|
||||
(as specified in TODO).</li>
|
||||
(as specified in <a id="id19" class="footnote_reference" href="#spec-encoding-orchard-fvk">16</a>).</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{fvk}_i, [\texttt{0x82}]))\)</span>
|
||||
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathit{FVK}_i, [\texttt{0x82}]))\)</span>
|
||||
.</li>
|
||||
<li>Let
|
||||
<span class="math">\(j\)</span>
|
||||
|
|
@ -645,7 +650,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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id19" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
|
||||
<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>
|
||||
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a rel="bookmark" href="#key-path-levels"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
|
||||
<ul>
|
||||
|
|
@ -658,7 +663,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 cybercoin 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="id20" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cybercoin testnets share
|
||||
: a constant identifying the cybercoin 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 cybercoin testnets share
|
||||
<span class="math">\(coin\_type\)</span>
|
||||
index
|
||||
<span class="math">\(1\)</span>
|
||||
|
|
@ -667,7 +672,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="id21" class="footnote_reference" href="#bip-0044">5</a>.</li>
|
||||
in sequentially increasing manner. Defined as in BIP 44 <a id="id22" 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>
|
||||
|
|
@ -689,7 +694,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="id22" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
path level as in <a id="id23" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
|
||||
|
|
@ -714,7 +719,7 @@ License: MIT</pre>
|
|||
<span class="math">\(m_\mathsf{Orchard} / purpose' / coin\_type' / account'\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of payment addresses for a given account, if they wish to maintain the user experience of giving a unique address to each recipient.</p>
|
||||
<p>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>
|
||||
|
|
@ -724,7 +729,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" 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">\(FVK\)</span>
|
||||
(as specified in <a id="id23" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">14</a>) is given by:</p>
|
||||
(as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">14</a>) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, FVK)\)</span>
|
||||
|
|
@ -736,7 +741,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" 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">\(ADDR\)</span>
|
||||
(as specified in <a id="id24" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">13</a>, including the lead bytes) is given by:</p>
|
||||
(as specified in <a id="id25" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">13</a>, including the lead bytes) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, ADDR)\)</span>
|
||||
|
|
@ -747,11 +752,11 @@ License: MIT</pre>
|
|||
</section>
|
||||
<section id="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding
|
||||
<span class="math">\(FVK\)</span>
|
||||
(as specified in TODO) is given by:</p>
|
||||
<span class="math">\(\mathit{FVK}\)</span>
|
||||
(as specified in <a id="id26" class="footnote_reference" href="#spec-encoding-orchard-fvk">16</a>) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, FVK)\)</span>
|
||||
<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>
|
||||
|
|
@ -773,7 +778,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" 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="id25" 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="id27" 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" 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>
|
||||
|
|
@ -897,7 +902,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 the production network, or <code>secret-orchard-extsk-test</code> for the test network.</p>
|
||||
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users (TODO: reference).</p>
|
||||
<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="#spec-encoding-orchard-sk">17</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -1032,10 +1037,26 @@ License: MIT</pre>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="nist-sp-800-38g" class="footnote">
|
||||
<table id="spec-encoding-orchard-fvk" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<td><a href="protocol/orchard.pdf">TODO Orchard FVK</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="spec-encoding-orchard-sk" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>17</th>
|
||||
<td><a href="protocol/orchard.pdf">TODO Orchard SK</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="nist-sp-800-38g" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>18</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>
|
||||
|
|
|
|||
22
zip-0032.rst
22
zip-0032.rst
|
|
@ -337,6 +337,8 @@ Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least
|
|||
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
|
||||
- Use :math:`I_L` as the master spending key :math:`\mathsf{sk}_m`.
|
||||
- Use :math:`I_R` as the master chain code :math:`\mathsf{c}_m`.
|
||||
- Return :math:`(\mathsf{sk}_m, \mathsf{c}_m)` as the master extended spending key
|
||||
:math:`m_\mathsf{Orchard}`.
|
||||
|
||||
Orchard child key derivation
|
||||
----------------------------
|
||||
|
|
@ -365,9 +367,9 @@ key structure.
|
|||
|
||||
Given an Orchard extended spending key :math:`(\mathsf{sk}_i, \mathsf{c}_i)`:
|
||||
|
||||
- Let :math:`\mathsf{fvk}_i` be the raw encoding of the Orchard full viewing key for :math:`\mathsf{sk}_i`
|
||||
(as specified in TODO).
|
||||
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{fvk}_i, [\texttt{0x82}]))`.
|
||||
- Let :math:`\mathit{FVK}_i` be the raw encoding of the Orchard full viewing key for :math:`\mathsf{sk}_i`
|
||||
(as specified in [#spec-encoding-orchard-fvk]_).
|
||||
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathit{FVK}_i, [\texttt{0x82}]))`.
|
||||
- Let :math:`j` be the index of the desired diversifier, in the range :math:`0\,.\!. 2^{88} - 1`.
|
||||
- :math:`d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))`.
|
||||
|
||||
|
|
@ -455,8 +457,8 @@ ZIP 32 derivation MUST support the following path for any account in range :math
|
|||
* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account'`.
|
||||
|
||||
Furthermore, wallets MUST support generating the default payment address (corresponding to the default
|
||||
diversifier for Orchard) for any account they support. They MAY also support generating a stream of payment
|
||||
addresses for a given account, if they wish to maintain the user experience of giving a unique address to
|
||||
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.
|
||||
|
||||
Note that a given account can have a maximum of :math:`2^{88}` payment addresses (unlike Sapling, all Orchard
|
||||
|
|
@ -497,10 +499,10 @@ a particular address.
|
|||
Orchard Full Viewing Key Fingerprints and Tags
|
||||
----------------------------------------------
|
||||
|
||||
An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding :math:`FVK` (as specified
|
||||
in TODO) is given by:
|
||||
An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding :math:`\mathit{FVK}` (as
|
||||
specified in [#spec-encoding-orchard-fvk]_) is given by:
|
||||
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, FVK)`.
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})`.
|
||||
|
||||
It MAY be used to uniquely identify a particular Orchard full viewing key.
|
||||
|
||||
|
|
@ -594,7 +596,7 @@ for the production network, or ``secret-orchard-extsk-test`` for the test networ
|
|||
|
||||
We define this encoding for completeness, however given that it includes the capability to derive child
|
||||
spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to
|
||||
users (TODO: reference).
|
||||
users [#spec-encoding-orchard-sk]_.
|
||||
|
||||
|
||||
Test Vectors
|
||||
|
|
@ -630,4 +632,6 @@ References
|
|||
.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.3: Sprout Shielded Payment Addresses <protocol/protocol.pdf#sproutpaymentaddrencoding>`_
|
||||
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.7: Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
|
||||
.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.15. Section 5.6.8: Sprout Spending Keys <protocol/protocol.pdf#sproutspendingkeyencoding>`_
|
||||
.. [#spec-encoding-orchard-fvk] `TODO Orchard FVK <protocol/orchard.pdf>`_
|
||||
.. [#spec-encoding-orchard-sk] `TODO Orchard SK <protocol/orchard.pdf>`_
|
||||
.. [#NIST-SP-800-38G] `NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption <https://dx.doi.org/10.6028/NIST.SP.800-38G>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue