BlockchainCommons / BlockchainCommons/zewif
Ambiguities in `Account` definition.
- Dominant language
- Rust
- Stars
- 1
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
There is an ambiguity in the import of legacy `zcashd` wallets into the ZeWIF format: the pre-BIP 39 seed type implies the existence of two seeds: the original seed derived from system randomness, and the seed derived from the mnemonic derived using the original seed as entropy.
The way that this worked in zcashd was that, in the v4.7.0 migration, the wallet would attempt to generate a mnemonic phrase, using the original seed as entropy. If generation of a phrase failed, the first byte of the seed was incremented by 1, and then the generation of a mnemonic was attempted again until a mnemonic was successfully generated.
This mnemonic was then used as the source of all spending keys from v4.7.0 onward, and provided a last-ditch mechanism by which someone who stored that generated phrase would at least have a chance of recovering their pre-v4.7.0 funds (the recovery mechanism for this was never implemented, and isn't really relevant to the ZeWIF migration, as what we're working from is a complete wallet database, not just the mnemonic phrase.
Since `SeedMaterial::PreBIP39Seed` implies two possible HD seeds, it would be useful to clarify how the `Account` type relates to the associated seed in the ZeWIF wallet. I *presume* that when an `Account` is associated with a pre-BIP-39 seed, this means that the account identifier relates specifically to the ordinary ZIP 32 derivation path from that seed. It would be useful to document this explicitly, and/or to include a seed fingerprint alongside the ZIP 32 account identifier in the account data.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.