New Ethereum BIP 44 Derivations differ from Trezor and MEW

[jamespic]

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]

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]

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]

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]

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]

@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]

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

[jamespic]

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]

I was not able to find them.

…

On Wed, Oct 24, 2018 at 3:06 PM James Pickering ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1185 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD1YSJh4w_MVyEeB3i0LtkODGFFgF-1wks5uoLpAgaJpZM4VUWoJ> .

[webmaster128]

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.