[ZIP TBD]: Draft for historical wallet key gen/derivation schemes#1176
[ZIP TBD]: Draft for historical wallet key gen/derivation schemes#1176dorianvp wants to merge 3 commits intozcash:mainfrom
Conversation
|
|
||
| (TODO: document whether mnemonic/seed originates from BIP 39 and how it was stored/encoded.) | ||
|
|
||
| ### Derivation / address generation |
There was a problem hiding this comment.
Expand using information from here: zingolabs/zingolib#2060 (comment)
| - Document the v4.7.0+ migration flow in more detail (how/when the emergency recovery phrase is generated, confirmation requirement, export mechanism via `z_exportwallet`, `zcashd-wallet-tool` behavior). | ||
| - Specify the exact derivation path structure used for the legacy account and any gap-limit expectations for recovery. | ||
|
|
||
| ## Zecwallet Lite |
There was a problem hiding this comment.
It might make more sense to rename this to just zecwallet, or zecwallet-lib, as both Zecwallet Lite and zecwallet-light-cli rely on the same library, and thus inherit the same behaviors.
There was a problem hiding this comment.
I disagree; don't forget that Zecwallet had a full-node variant that was simply a UI atop the zcashd RPC API. The behavior here was specifically for Zecwallet Lite, in both its desktop and mobile wallet versions.
|
|
||
| ### Summary | ||
|
|
||
| Historically, `zcashd` generated keys from system randomness. |
There was a problem hiding this comment.
This summary should include the pre-v4.7.0 HD derivation of Sapling addresses.
|
|
||
| For Sapling, `zcashd` implemented HD derivation according to ZIP 32, but used a seed generated directly from system randomness, rather than seed material derived from a BIP 39 mnemonic phrase. | ||
|
|
||
| In `zcashd` v4.7.0, the wallet added support for deriving the wallet’s HD seed from a mnemonic phrase (BIP 39) and referred to the HD seed derived from the emergency recovery phrase as the wallet’s “mnemonic seed”. |
There was a problem hiding this comment.
This needs to document the approach that zcashd took to creating seed phrases for existing wallets in particular and clearly document how to recover funds from such wallets, see https://github.com/zcash/zcash/blob/master/doc/release-notes/release-notes-4.7.0.md?plain=1#L71-L79
|
|
||
| After v4.7.0, new addresses are derived from the mnemonic seed using ZIP 32 and ZIP 316. | ||
|
|
||
| For legacy RPC behavior such as `z_getnewaddress`, `zcashd` derives Sapling addresses under a high account index `account = 0x7FFFFFFF` to avoid collision with Sapling addresses for account 0. |
There was a problem hiding this comment.
This needs to also explain the change in behavior of getnewaddress for derivation of transparent addresses, and how the legacy account is structured. Specifically, the semantics of the legacy pool as an undifferentiated pool of transparent funds (that is not partitioned by address) needs to be documented.
|
|
||
| ### Derivation / address generation | ||
|
|
||
| Sapling keys are derived using ZIP 32. |
There was a problem hiding this comment.
Describe the pre-v4.7.0 derivation process here, and how it relates to extracting a pre-v4.7.0 HD seed from the mnemonic phrase via the nonstandard pathway described above.
|
|
||
| ### Recovery implications | ||
|
|
||
| Recovery tooling may need to support Sapling HD derivation from wallet-internal seed material that is not reproducible from a BIP 39 mnemonic. |
There was a problem hiding this comment.
As described in the v4.7.0 release notes, the mnemonic generated for existing wallets was not random; it was an encoding of the existing HD seed as a BIP 39 phrase. Such wallets then had two seeds: the original HD seed, which we wanted to make recoverable via the nonstandard pathway, and the new seed that was generated by hashing the phrase according to BIP 39. After the v4.7.0 upgrade, all new addresses generated by the wallet were produced via derivation from the new seed, with the particular carve-outs in derivation paths for the legacy transparent pool and z_getnewaddress.
|
|
||
| ## `zcash_client_sqlite` | ||
|
|
||
| TBD |
There was a problem hiding this comment.
Key derivation in zcash_client_backend/zcash_client_sqlite based wallets has always been based on BIP 39 seed phrases. The "default transparent address" is the address derived according to BIP 44 at child index 0; additional transparent receivers may have been generated by either normal BIP 44 derivation or by unified address derivation according to ZIP 317.
|
|
||
| TBD | ||
|
|
||
| # Security and Privacy Considerations |
There was a problem hiding this comment.
Note that the Security and Privacy Considerations section is supposed to go directly after the Motivation section
|
|
||
| # Reference Implementation | ||
|
|
||
| None. |
2 participants
Closes #1175.