implement `core/signing-hd-wallet`
This signing driver will be the primary driver used for the browser extension. The rough implementation plan (pulled from the design doc):
Mnemonic Seed Phrase (& Key Generation)
The mnemonic seed phrase will be a 24-word (256 bit entropy) phrase generated via the BIP-39 standard. This results in a root seed that is further used, in combination with a derivation path, to generate each individual keypair per party. The mnemonic is also protected with a user-defined password. We plan to use the same password to encrypt the extension storage, so users don’t need to manage two passwords.
The existing standard for deriving ed25519 keys from a root seed is specified in SLIP-0010. We plan to use existing, well-supported libraries to achieve this:
- @scure/bip39: TS library for generating mnemonics (audited, minimal dependencies)
- micro-key-producer: TS library for generating child ed25519 keys according to SLIP-10 (audited, minimal deps)
In order to generate HD wallets, we need a derivation path for determinism. The standard here also comes from Bitcoin in BIP-44, and generically a derivation path looks like:
m / purpose' / coin_type' / account' / change / address_index
For Canton purposes, we will use a path that looks like: m / 44’ / 6767’ / account’ / 0’ / index’, where:
- 44: “Purpose is a constant set to 44'” - Bip44 spec
- 6767: The coin value for Canton Coin, defined in SLIP-44 (“Registered Coin Types”)
- partyHint: The final partyId depends on the generated key, which we don’t have at this stage. As a side effect, this technically allows multiple parties to be generated with the same hint by incrementing the
indexsegment (each resulting with different fingerprints). However we expect thatindexwill just be hardcoded to0’for the majority of cases. - change: Not relevant to Canton AFAICT, so we’ll hardcode to 0’
Because all parties are generated based on the same root seed, derived from the initial mnemonic, then all subsequently generated parties (and their balances) can be restored from the same phrase.
Recovery process:
In order to recover wallets, the recommended strategy is:
- Import the mnemonic phrase and regenerate the seed.
- Traverse the derivation tree, starting with
index == 0and regenerate keys. - For each key, lookup the transaction history on ledger to see if this was actually a real wallet (for Canton, perhaps a topology lookup is sufficient to confirm the party was allocated). Similar to wallet sync logic we have in Wallet Gateway (Remote).
- Stop importing when the keys no longer correspond to existing parties.