mirror of https://github.com/zcash/zips.git
ZIP 224: update for unified addresses and viewing keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
cbf2878cbe
commit
5a925a44fe
|
|
@ -50,14 +50,14 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
</ul>
|
||||
<p>We use the "simplified SWU" algorithm to define an infallible
|
||||
<span class="math">\(\mathsf{GroupHash}\)</span>
|
||||
, instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft <a id="id7" class="footnote_reference" href="#ietf-hash-to-curve">32</a> (but the protocol specification takes precedence in the case of any discrepancy).</p>
|
||||
, instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft <a id="id7" class="footnote_reference" href="#ietf-hash-to-curve">33</a> (but the protocol specification takes precedence in the case of any discrepancy).</p>
|
||||
<p>The presence of the curve cycle is an explicit design choice. This proposal only uses half of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be leveraged by future protocol updates.</p>
|
||||
<ul>
|
||||
<li>Curve specifications: <a id="id8" class="footnote_reference" href="#protocol-pallasandvesta">16</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{GroupHash}\)</span>
|
||||
: <a id="id9" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">17</a></li>
|
||||
<li>Supporting evidence: <a id="id10" class="footnote_reference" href="#pasta-evidence">33</a></li>
|
||||
<li>Supporting evidence: <a id="id10" class="footnote_reference" href="#pasta-evidence">34</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="proving-system"><h3><span class="section-heading">Proving system</span><span class="section-anchor"> <a rel="bookmark" href="#proving-system"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -110,14 +110,14 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
, instead of being a component of the spending key.</li>
|
||||
<li>All diversifiers now result in valid payment addresses.</li>
|
||||
</ul>
|
||||
<p>Keys and addresses are encoded using Bech32. Orchard addresses used with the Zcash Mainnet have the prefix "zo" (compared to "zc" for Sprout and "zs" for Sapling).</p>
|
||||
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="id20" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="id21" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
|
||||
<p>Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only derivation mechanism (similar to Sprout).</p>
|
||||
<ul>
|
||||
<li>Key components diagram: <a id="id20" class="footnote_reference" href="#protocol-addressesandkeys">7</a></li>
|
||||
<li>Key components specification: <a id="id21" class="footnote_reference" href="#protocol-orchardkeycomponents">11</a></li>
|
||||
<li>Encodings and HRPs: <a id="id22" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">18</a> <a id="id23" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">19</a> <a id="id24" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a> <a id="id25" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a></li>
|
||||
<li>HD key derivation specification: <a id="id26" class="footnote_reference" href="#zip-0032">29</a></li>
|
||||
<li>Design rationale: <a id="id27" class="footnote_reference" href="#design-keys">24</a></li>
|
||||
<li>Key components diagram: <a id="id22" class="footnote_reference" href="#protocol-addressesandkeys">7</a></li>
|
||||
<li>Key components specification: <a id="id23" class="footnote_reference" href="#protocol-orchardkeycomponents">11</a></li>
|
||||
<li>Encodings and HRPs: <a id="id24" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">18</a> <a id="id25" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">19</a> <a id="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a> <a id="id27" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a></li>
|
||||
<li>HD key derivation specification: <a id="id28" class="footnote_reference" href="#zip-0032">29</a></li>
|
||||
<li>Design rationale: <a id="id29" class="footnote_reference" href="#design-keys">24</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a rel="bookmark" href="#notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -128,9 +128,9 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
<span class="math">\(\psi\)</span>
|
||||
and
|
||||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
are derived from a random seed (as with Sapling after ZIP 212 <a id="id28" class="footnote_reference" href="#zip-0212">30</a>).</p>
|
||||
are derived from a random seed (as with Sapling after ZIP 212 <a id="id30" class="footnote_reference" href="#zip-0212">30</a>).</p>
|
||||
<ul>
|
||||
<li>Orchard notes: <a id="id29" class="footnote_reference" href="#protocol-notes">8</a></li>
|
||||
<li>Orchard notes: <a id="id31" class="footnote_reference" href="#protocol-notes">8</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="nullifiers"><h3><span class="section-heading">Nullifiers</span><span class="section-anchor"> <a rel="bookmark" href="#nullifiers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -144,14 +144,14 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
<span class="math">\(\mathcal{G}\)</span>
|
||||
is a fixed independent base.</p>
|
||||
<ul>
|
||||
<li>Poseidon: <a id="id30" class="footnote_reference" href="#protocol-poseidonhash">13</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="id31" class="footnote_reference" href="#design-nullifiers">28</a></li>
|
||||
<li>Poseidon: <a id="id32" class="footnote_reference" href="#protocol-poseidonhash">13</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="id33" class="footnote_reference" href="#design-nullifiers">28</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="signatures"><h3><span class="section-heading">Signatures</span><span class="section-anchor"> <a rel="bookmark" href="#signatures"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Orchard uses RedPallas (RedDSA instantiated with the Pallas curve) as its signature scheme in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).</p>
|
||||
<ul>
|
||||
<li>RedPallas: <a id="id32" class="footnote_reference" href="#protocol-concretereddsa">14</a></li>
|
||||
<li>RedPallas: <a id="id34" class="footnote_reference" href="#protocol-concretereddsa">14</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -171,7 +171,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
field, combined with the consensus checks that each pool's balance cannot be negative, together enforce that any potential counterfeiting bugs in the Orchard protocol or implementation are contained within the Orchard pool, and similarly any potential counterfeiting bugs in existing shielded pools cannot cause inflation of the Orchard pool.</li>
|
||||
<li>Spending funds residing in the Orchard pool to a non-Orchard address will reveal the value of the transaction. This is a necessary side-effect of the transparent turnstile, but can be mitigated by migrating the majority of shielded activity to the Orchard pool and making these transactions a minority. Wallets should convey within their transaction creation UX that amounts are revealed in these situations.
|
||||
<ul>
|
||||
<li>Wallets should take steps to migrate their user bases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="id33" class="footnote_reference" href="#zip-0315">31</a></li>
|
||||
<li>Wallets should take steps to migrate their user bases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="id35" class="footnote_reference" href="#zip-0315">31</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
|
@ -439,10 +439,18 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="ietf-hash-to-curve" class="footnote">
|
||||
<table id="zip-0316" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>32</th>
|
||||
<td><a href="zip-0316">ZIP 316: Unified Addresses and Unified Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="ietf-hash-to-curve" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>33</th>
|
||||
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html">draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -450,7 +458,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
<table id="pasta-evidence" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>33</th>
|
||||
<th>34</th>
|
||||
<td><a href="https://github.com/zcash/pasta">Pallas/Vesta supporting evidence</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
|
|
@ -164,11 +164,13 @@ changes:
|
|||
of the spending key.
|
||||
- All diversifiers now result in valid payment addresses.
|
||||
|
||||
Keys and addresses are encoded using Bech32. Orchard addresses used with the Zcash Mainnet
|
||||
have the prefix "zo" (compared to "zc" for Sprout and "zs" for Sapling).
|
||||
There is no Bech32 encoding defined for an individual Orchard shielded payment address,
|
||||
incoming viewing key, or full viewing key. Instead we define unified payment addresses and
|
||||
viewing keys in [#zip-0316]_. Orchard spending keys are encoded using Bech32m as specified
|
||||
in [#protocol-orchardspendingkeyencoding]_.
|
||||
|
||||
Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt
|
||||
the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only
|
||||
the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only
|
||||
derivation mechanism (similar to Sprout).
|
||||
|
||||
- Key components diagram: [#protocol-addressesandkeys]_
|
||||
|
|
|
|||
Loading…
Reference in New Issue