Skip to content
This repository has been archived by the owner on Jun 16, 2022. It is now read-only.

New Ethereum BIP 44 Derivations differ from Trezor and MEW #1185

Closed
jamespic opened this issue Jul 18, 2018 · 9 comments
Closed

New Ethereum BIP 44 Derivations differ from Trezor and MEW #1185

jamespic opened this issue Jul 18, 2018 · 9 comments

Comments

@jamespic
Copy link

Ledger Live uses "new style" BIP 44 derivations for Ethereum addresses. I assume the reason for this is to more closely align with other implementations, but it appears that this is not what has happened.

Ledger Live uses m/44'/60'/x'/0/0 for addresses, but Trezor and MEW use m/44'/60'/0'/0/x, which also seems to be the consensus that has been reached on EIP 84. This will lead to the same derivation for the first address, but different derivations for subsequent addresses.

@gre
Copy link
Contributor

gre commented Jul 18, 2018

I guess one problem with m/44'/60'/0'/0/x derivation is privacy: you can easily figure out all the addresses connected. with hardened derivation, you need the device.

to quote one comment discussed in the EIP 84

what you're giving up for efficiency is privacy. I'd like to make it as private as you'd desire it to be.

so this is a compromise. It was internal decided to do this. I'm not sure what should be done about it, weither or not we want to offer possibility to have the 2 ways of derivating from inside Ledger Live... but you can technically do it on MEW as we still support the previous path discoverability.

( discussion related MyCryptoHQ/MyCrypto#2070 )

@jamespic
Copy link
Author

The privacy concerns are slightly overstated. You can't figure out that two sibling addresses are related unless you've got the parent public key. However, I agree that for Ledger this would be a problem, as the legacy derivation was m/44'/60'/0'/0, which happens to be the parent key.

But if this is definitely the approach, I can work with it. I'm debating how to implement this in SpaceSuit, and worst case, I'll add three radio buttons, for old style, new style, and EIP 84.

@mratsim
Copy link

mratsim commented Oct 4, 2018

In my opinion the change made in Ledger Live was a bit strong-armed.

Everyone was taken by surprise and after the fact you asked the other open-source clients to catch up MyCryptoHQ/MyCrypto#2070. (LL release on July 9, issue open in MyCrypto on July 14).

There is still no FAQ for the end users even though /r/ledgerwallet is full of confused users, some thinking that their funds are lost. See a non-exhaustive list here.

@bgits
Copy link

bgits commented Oct 24, 2018

So if someone has a seed they used with trezor to derive accounts, how would they access the derived accounts from the ledger nano s?

@jamespic
Copy link
Author

@bgits For now, using something that supports the Trezor derivations, such as MyEtherWallet, MyCrypto, or (my personal baby) SpaceSuit. For Ledger Live, one option would be to add support for Trezor-style addresses, along the same lines as the legacy Ledger App derivations, so they're discovered automatically by Ledger Live.

@bgits
Copy link

bgits commented Oct 24, 2018

@jamespic how would the derivation path be set in any of these?

@jamespic
Copy link
Author

The implementations I mentioned all have a config option to select the derivation path. The best possible UX would be for Ledger Live to check if any Trezor-style paths have non-zero balance or nonce at startup, and add them automatically, similar to what it does for legacy Ledger App addresses.

@bgits
Copy link

bgits commented Oct 24, 2018 via email

@webmaster128
Copy link

you can easily figure out all the addresses connected.

You can only use public key -> public key derivation if you get the extended public key. An extended public key is a secp256k1 public key plus the chain code of m/44'/60'/0'/0/0. This chain code is only available with the secret or if you make it available explicitly (e.g. by providing pubkey+chain code to a webshop webserver).

to quote one comment discussed in the EIP 84

The quoted comment was put out of the original context. It was about using multiple addresses vs. one address, not about the kind of addresses used. The change m/44'/60'/x'/0/0 vs. m/44'/60'/0'/0/x is unrelated to the quote.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants