Better handling of paths in HD keyrings

Right now, the main keyring we use is Ed25519SimpleAddressKeyringEntry which hardcodes the beginning of a path and just increments the last value to produce multiple addresses. A KeyringEntry has just one command to create a new key, which accepts no arguments.

export interface KeyringEntry {
...
  // createIdentity will create one new identity
  readonly createIdentity: () => Promise<LocalIdentity>;
...
}

This is exposed in the UserProfile as:

  // creates an identity in the n-th keyring entry of the primary keyring
  public async createIdentity(n: number): Promise<LocalIdentity> {
    const entry = this.entryInPrimaryKeyring(n);
    return entry.createIdentity();
  }

This doesn’t allow us to specify the path to use for hd keys, or to import a private key from another key store. It also is not the cleanest way to specify the algorithm. I mean, n=0 could be ed25519 and n=1 secp256k1, but that is not so clear.

We should make it easy to either import existing private keys, or to do something like “Create a new secp256k1 key with path 44’/1’/2’/0/x where x is one higher that the last value you generated with that prefix”.

Let’s figure out the nicest API for the user, then work on implementing it. As all the pieces are there, it shouldn’t be too much hard crypto work, just API polish.

[ethanfrey]

Hmmm… maybe two functions…

createBip44Identity(coinType: Slip0010RawIndex, account: Slip0010RawIndex, change: Slip0010RawIndex, addressIndex: Slip0010RawIndex)

createBip32Identity(path: Slip0010RawIndex[])

[ethanfrey]

this keeps all the strangeness outside of the library and all the correctness and hard work inside.

Best criteria I have heard for library boundaries