Skip to content

Commit

Permalink
Regenerate HTML.
Browse files Browse the repository at this point in the history 
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
  • Loading branch information
@daira
daira committed Oct 25, 2021
1 parent 9f697ee commit d2eaf83
Show file tree
Hide file tree
Showing 5 changed files with 169 additions and 68 deletions.
2 changes: 1 addition & 1 deletion README.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -140,7 +140,7 @@ Index of ZIPs
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402.rst">New Wallet Database Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403.rst">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416.rst">RPC support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416.rst">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
<tr> <td><strike>1001</strike></td> <td class="left"><strike><a href="zip-1001.rst">Keep the Block Distribution as Initially Defined — 90% to Miners</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1002</strike></td> <td class="left"><strike><a href="zip-1002.rst">Opt-in Donation Feature</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1003</strike></td> <td class="left"><strike><a href="zip-1003.rst">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></strike></td> <td>Obsolete</td>
Expand Down
2 changes: 1 addition & 1 deletion index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -113,7 +113,7 @@
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402">New Wallet Database Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416">RPC support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
<tr> <td><strike>1001</strike></td> <td class="left"><strike><a href="zip-1001">Keep the Block Distribution as Initially Defined — 90% to Miners</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1002</strike></td> <td class="left"><strike><a href="zip-1002">Opt-in Donation Feature</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1003</strike></td> <td class="left"><strike><a href="zip-1003">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></strike></td> <td>Obsolete</td>
Expand Down
33 changes: 24 additions & 9 deletions zip-0032.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@
<li>Wallets only need to store a single seed (particularly useful for hardware wallets).</li>
<li>A one-time backup of the seed (usually stored as a word phrase <a id="id8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
<li>Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.</li>
<li>View authority or spend authority can be delegated independently for sub-trees without compromising the master seed.</li>
<li>Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.</li>
</ul>
<p>At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.</p>
</section>
Expand Down Expand Up @@ -654,6 +654,7 @@
is defined to be
<span class="math">\(d_{i,0}.\)</span>
</p>
<p>Although the diversifier <em>key</em> is derived from the full viewing key which is at the Account level, the resulting diversified addresses are derived from the key at the non-change child of that level, as described in <a href="#orchard-key-path">Orchard key path</a> below.</p>
</section>
</section>
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a rel="bookmark" href="#specification-wallet-usage"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
Expand All @@ -670,7 +671,7 @@
) 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="id21" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cybercoin 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="id21" 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>
Expand All @@ -681,9 +682,14 @@
<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>
</ul>
<p>Unlike BIP 44, none of the shielded key paths have a
<p>In BIP 44, there is also a
<span class="math">\(change\)</span>
path level. The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating external and internal address usage. Shielded addresses are never publicly visible in transactions, which means that sending change back to the originating address is indistinguishable from using a change address.</p>
unhardened path level as a child of
<span class="math">\(account\)</span>
. This level is not present in the Sprout and Sapling key paths. It <em>is</em> present in Orchard, but as a hardened path level.</p>
<p>The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating external and internal address usage. For Sprout and Sapling, it was reasoned that shielded addresses are never publicly visible in transactions, and so sending change back to the originating address would be indistinguishable from using a change address. However, this reasoning does not apply if we give out incoming viewing keys, and so for Orchard the
<span class="math">\(change\)</span>
level has been reintroduced. This ensures that an Orchard incoming viewing key will only be able to view incoming payments, not incoming change, which was deemed to be more useful for anticipated applications of incoming viewing keys (such as a merchant terminal or a charity donation address).</p>
</section>
<section id="sapling-key-path"><h3><span class="section-heading">Sapling key path</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Sapling provides a mechanism to allow the efficient creation of diversified payment addresses with the same spending authority. A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.</p>
Expand All @@ -707,6 +713,9 @@
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
.</li>
</ul>
<p><cite>zcashd</cite> version 4.5.2 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account
<span class="math">\(\mathtt{0x7FFFFFFF}\)</span>
.</p>
</section>
<section id="sprout-key-path"><h3><span class="section-heading">Sprout key path</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Wallets implementing Sprout ZIP 32 derivation MUST support the following path:</p>
Expand All @@ -717,16 +726,22 @@
</ul>
</section>
<section id="orchard-key-path"><h3><span class="section-heading">Orchard key path</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.</p>
<p>The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard ZIP 32 derivation MUST support the following path for any account in range
<p>Orchard supports diversified addresses with the same spending authority (like Sapling). Unlike Sapling and Sprout, we reintroduce the
<span class="math">\(change'\)</span>
level of the key path, so that the spending authorities generated for incoming payments and for change are distinct. The motivation for this distinction is to allow giving out an incoming viewing key that is only able to see incoming payments, and not incoming change.</p>
<p>A group of diversified addresses with the same spending authority shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.</p>
<p>The key path levels include an account identifier, which in all user interfaces should be represented as a "bucket of funds" under the control of a single spending authority. Wallets implementing Orchard ZIP 32 derivation MUST support the following two paths for any account in range
<span class="math">\(\{ 0\,.\!. 2^{31} - 1 \}\)</span>
:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Orchard} / purpose' / coin\_type' / account'\)</span>
.</li>
<span class="math">\(m_\mathsf{Orchard} / purpose' / coin\_type' / account' / 0'\)</span>
(for incoming payments);</li>
<li>
<span class="math">\(m_\mathsf{Orchard} / purpose' / coin\_type' / account' / 1'\)</span>
(for change).</li>
</ul>
<p>Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of diversified payment addresses for a given account, if they wish to enable users to give a unique address to each recipient.</p>
<p>Furthermore, wallets MUST support generating a default payment address and a default change address (each corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of diversified payment addresses (based on the non-change key path) for a given account, if they wish to enable users to give a unique address to each recipient. A single address using the default diversifier SHOULD be used for change.</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>
Expand Down
Loading

0 comments on commit d2eaf83

Please sign in to comment.