Merge pull request #564 from daira/zip-ivk-changes

ZIPs 32 and 316: Refine how IVK components are derived, and other cleanups

zip-0032.html

@@ -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>
@@ -670,7 +670,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>
@@ -707,6 +707,11 @@
                         <span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
                     .</li>
                 </ul>
+                <p><cite>zcashd</cite> version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account
+                    <span class="math">\(\mathtt{0x7FFFFFFF}\)</span>
+                , using hardened derivation for
+                    <span class="math">\(address\_index\)</span>
+                .</p>
             </section>
             <section id="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>

zip-0032.rst

@@ -62,8 +62,8 @@ advantages over random generation:
   from all future addresses.
 - Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level
   structures.
-- View authority or spend authority can be delegated independently for sub-trees without compromising the
-  master seed.
+- Viewing authority or spending authority can be delegated independently for sub-trees without compromising
+  the master seed.
 
 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
@@ -401,9 +401,9 @@ hardened derivation:
 - :math:`purpose`: a constant set to :math:`32'` (or :math:`\texttt{0x80000020}`) following the BIP 43
   recommendation. It indicates that the subtree of this node is used according to this specification.
 
-- :math:`coin\_type`: a constant identifying the cybercoin that this subtree's keys are used with. For
+- :math:`coin\_type`: 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
-  [#slip-0044]_. Note that in keeping with that document, all cybercoin testnets share :math:`coin\_type`
+  [#slip-0044]_. Note that in keeping with that document, all cryptocurrency testnets share :math:`coin\_type`
   index :math:`1`.
 
 - :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in
@@ -442,6 +442,9 @@ they MAY additionally support a non-hardened :math:`address\_index` path level a
 
 * :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index`.
 
+`zcashd` version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase
+under account :math:`\mathtt{0x7FFFFFFF}`, using hardened derivation for :math:`address\_index`.
+
 Sprout key path
 ---------------