Support Ethereum-type derivation paths

[joelamouche]

In common/packages/keyring/src/keyring.ts
there is a comment : FIXME Need to support Ethereum-type derivation paths

Is this fixed yet? Are derivation path working for ethereum? If yes, what is the format?

Thanks in advance @jacogr

[jacogr]

No. It only does the Substrate style. (Which is not compatible with Ethereum at all)

[joelamouche]

Do you have an idea of the amount of work and complexity it would take to support that?

[jacogr]

Implement bip-44, basically. The big issue I have with this is that I'm trying to get rid on not-frequently-used stuff, so generally not happy to just reach for JS libs and get it and all it's dependencies.

The only complexity is that Substrate always uses suri, so in the case of Ethereum the string (before stripping) won't be full compliant, i.e.

seed 0x1234 with path m/44'/0'/0'/1/1 would probably look like 0x1234/44'/0'/0'/1/1 in suri-like format before being used.

(There is a use for bip-44 style derivation in the case of eg. Ledger as well, where ed keys are derived that way, even though it supports Polkadot/Kusama)

[jacogr]

I'm quite happy to do this on the apps UI first, with hdkey libs (none specific preferred), before adding it here.

So my concern with the crypto libs is stuff like this - https://github.com/cryptocoinjs/hdkey/blob/master/package.json#L39 - it actually took ages to get secp256k1 our and deduped (so elliptic is not used here only), both are absolutely massive.

So would suggest -

• add via apps UI
• apps UI does derivation
• derived keys passed through the the keyring

It will also be less complex, just pull in libs and be done with it.

[crystalin]

Hi @jacogr ,
What is the status on this?

[jacogr]

It is not on the to-do-immediately list, so not a priority to get done.

I have taken some looks at some of the derivations libs out there and it pulls in the wide whole world of dependencies in all cases I have seen. So atm have no clean, light solution for this - which is needed if it as to go into common.

[crystalin]

I'd be happy to get your suggestion on what should be done here and what library you suggest and maybe @joelamouche will work to have it implemented. It is not an urgent matter but it feels weird being able to use the private key and not the mnemonic for our chain.

[jacogr]

So HDKey, aka https://github.com/cryptocoinjs/hdkey/blob/master/lib/hdkey.js, is actually a good candidate - and the guys are solid.

So if we can extract the derive (which links to deriveChild) from that and make it work with the keyring, it can work. (Out of the box they really all focus on their keypair types, which is not compatible.) So basically, my approach would be -

• use hdkey as a base (we certainly on't need serialize, toJSON, etc.)
• rip out the derives and do them in TS
• adjust so it uses the libraries already available in util-crypto (all the stuff is there, eg. secp2561k1, hashing, ...)
• make it work with the pairs (would need some adjustment)
• add tests

I don't believe it is major, but don't see much of another option without some serious hacks. The above approach is very lightweight.

[joelamouche]

@jacogr Hi, justg pinging you because I'm not sure you're receiving notifications about my progress and comments on #858

[jacogr]

Will look at the comments, I have only peeked in at the code, sorry about that.

[joelamouche]

Cool thanks

[joelamouche]

done in #894

[polkadot-js-bot]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.