]> Untitled Git - bdk/commit
[keys] Implement `DerivableKey<Ctx>` for `(GeneratedKey<Mnemonic, Ctx>, Option<String>)`
authorAlekos Filini <alekos.filini@gmail.com>
Wed, 13 Apr 2022 10:37:27 +0000 (12:37 +0200)
committerAlekos Filini <alekos.filini@gmail.com>
Wed, 13 Apr 2022 10:37:27 +0000 (12:37 +0200)
commite4eb95fb9cfbae3596deb310984fa18462d1b30c
treef3cf1b11ce84731c01ac7283424ca81768e6de87
parentc307bacb9cd0e55feafe1ece49b3d119c5dd733a
[keys] Implement `DerivableKey<Ctx>` for `(GeneratedKey<Mnemonic, Ctx>, Option<String>)`

This lets us use a tuple of (generated mnemonic, optional passphrase) as
a `DerivableKey` directly, without extracting the inner mnemonic from the
`GeneratedKey` wrapper. For BIP39 keys specifically it doesn't make much
difference because the mnemonic format doesn't encode the network, but in
general this is not the case and having a consistent API will make it
harder for people to make mistakes.

To explain why we should not extract the key: some key formats (like
BIP32 extended keys) are network-specific, meaning that if somebody
tries to use a Testnet key on a Mainnet BDK wallet, it won't work.

However, when we generate a new key we would like to be able to use that
key on any network, but we need to set some kind of placeholder for the
`network` field in the structure. This is why (or at least one of the
reasons why) we wrap the key in the `GeneratedKey` struct: we keep track
of the "valid_networks" separately, which means that even if we set our
BIP32 xprv to be a "Mainnet" key, once we go try creating a wallet with
that key BDK is smart enough to understand that `GeneratedKey`s have
their own separate set of valid networks and it will use that set to
validate whether the key can be used in the wallet or not.
src/keys/bip39.rs