Added Ledger support to the wallet.

[murisi]

Describe your changes

Added Ledger support to the namadaw command, expanded the Store to also hold derivation paths and public keys, and attempted to simplify the wallet logic. More specifically:

• Derivation paths are now stored in the wallet to ease future signing operations
• Public keys are now stored in the wallet so that the namadaw key list command remains as informative even in the absence of the secret key (which may be being stored externally on a hardware wallet)
• Modified the key generation command to always generate and print out a seed phrase
• Encryption is now done in store.rs to ensure that the key derivations are always maximized and are done correctly:
  • I.e. a public key and public key hash of the same alias should always be derived from inserting secret key to wallet
• The SDK now takes derivation paths using the type DerivationPath instead of String
  • This enabled the removal of string parsing logic (like checking for "default" keyword) from the SDK
• Broke up the SDK key derivation function because it was doing many things and its parameters were like flags
• Implemented key derivation given a derivation path using the hardware wallet
  • This is dependent upon a ledger-namada branch enabling SLIP10 and returns larger key byte vectors that contain the key discriminant byte: https://github.com/heliaxdev/ledger-namada/tree/murisi/fix-rs-0.24.0
• Enabled transactions to be signed using the hardware wallet when it is connected
  • This is dependent upon a ledger-namada branch fixing the hashing of signature sections involved in multisig transactions: https://github.com/heliaxdev/ledger-namada/tree/murisi/fix-rs-0.24.0
• Parameterized SDK functions depending on randomness with a randomness parameter
• Removed code that allowed multiple wallet entries sharing the same alias to be inserted separately
• Implemented Serde (de)serialization of public keys and derivation paths to enable Store (de)serialization
• Augmented the namadaw key list command to also print out public keys (labelled as external) even when no corresponding secret key exists

closes #70

Indicate on which release or other PRs this topic is based on

Checklist before merging to draft

• I have added a changelog
• Git history is in acceptable state

[cwgoes]

Most of the changes look fine, but I have some minor concerns about the flow.

[karbyshev]

Why was it introduced? Can DerivationPath::from_path_str be used instead, which also takes the scheme into account?

[karbyshev]

For SchemeType::Ed25519 scheme, all path segments must be hardened.

[murisi]

I see your point. FromStr was introduced to support the implementation of Serde::Deserialize for DerivationPath. And this is required in order to be able to store DerivationPaths in the wallet's Store, which itself is deserialized from file storage using Serde. I guess requiring scheme information to deserialize derivation paths would mean having to tag derivation paths with their scheme types. Couldn't we instead just deserialize all well-formatted (untagged) derivation paths (e.g. m/.../.../...) and delay the hardening/validations to when the actual SLIP10/BIP32 key computations are actually computed?

On the second point: I believe that all path segments are still being hardened for SchemeType::Ed25519. The slip10_ed25519::derive_ed25519_private_key function hardens all indices using the statement let hardened_index = 0x80000000 | *i;. As a separate thought: Instead of implicitly hardening Ed25519 paths, have we considered just rejecting non-hardened Ed25519 paths as is done in one of the implementations linked to from the SLIP10 specification? See https://github.com/elucidsoft/dotnetstandard-bip32/blob/master/dotnetstandard-bip32/BIP32.cs#L65 where they use the regex ^m(\/[0-9]+')+$ for derivation paths.

[karbyshev]

I guess requiring scheme information to deserialize derivation paths would mean having to tag derivation paths with their scheme types.

I would prefer this solution. I think that explicit storage of the scheme tag might be also useful from the user perspective.