Ledger now use BIP44 for accounts address derivation

[gre]

Hi, I'm gre from Ledger Live team.
Since Ledger Live release, Ledger is now derivating Ethereum and Ethereum Classic accounts by following BIP44 standard.

what changes

Ledger Ethereum Chrome Wallet used to derive only one address at m/44'/60'/0'/0 (NB: without the last /0 of BIP44).
MEW/MyCrypto have so far followed this idea that Ledger's "root" is at m/44'/60'/0' and therefore have chosen to derive pages of addresses by using m/44'/60'/0'/x (where x is a value from 0 to +inf)

in Ledger Live instead, the idea is to follow BIP44, which means the first address is derived on m/44'/60'/0'/0/0, the second on m/44'/60'/1'/0/0, and so on,.. so in other words using the account field of BIP44. (m/44'/60'/x'/0/0)

rationale

The benefit of this is that, as we increment an "hardened" path so it's more "secure" in term of privacy. We also use the same BIP44 convention for all cryptocurrencies so it unifies our approach and codebase.
The main change from your side is that, is as it's not a public derivation, you can't derive like you do, without the device, you will need to always ask the device to derive each address.

current actions and workaround

Since our release, we've seen some users a bit confused by this. To cover these issues, we have been scanning both the "legacy" paths and the new paths (1.0.0). Moreover, a second workaround was added (1.0.2): we will also always scan the first 5 addresses of MyCrypto even if there are "empty" accounts in the middle.. because, as we follow BIP44, when scanning accounts is to stop at first account without transactions. (the fact MEW allow users to take any arbitrary address from the pages have a cost. our tradeoff is so far to assume a user don't paginate more than the first page unless he have finished its account, which might still be not true,.. past first page, if users don't leave "empty" accounts and use the address in order, they should be fine)

Finally, we are also helping our users discovering their new Ledger Live path in MyCrypto but this is getting a bit more hairy to explain to them. Basically you can use the "Custom field" and manually input: m/44'/60'/0'/0 then select the first derived address (this is LedgerLive first account), then switch to m/44'/60'/1'/0, select the first address (this is LedgerLive second account), and so on..

But this is a temporary solution for now. I feel we should have a better option offered, right?

what you could do

here is suggestion of what you could have:

• a new "Ledger Live" option that would derive the addresses using the hardened path. Not sure how reachable for you to paginate address like before you will always need the device and it can take some times to derive addresses (like 1-2s per page)
  • if you do so, please also follow BIP44 spec part that says: Software should prevent a creation of an account if a previous account does not have a transaction history (meaning none of its addresses have been used before).
• the previous Ledger option might be renamed as Ledger (legacy)

[tayvano]

So there are a few different things going on here. It should be noted this is for the ETH network only.

1. When a user selects "Ledger" and is presented with the mnemonic modal, we should default to the new path (below in 4). It should be labeled Ledger (ETH).

2. We should make the old Ledger path available in the dropdown under Ledger - Legacy (ETH)

3. If a user connects via Ledger, we should encourage them to check the Ledger - Legacy (ETH) path if they don't see their balance. This messaging should be placed in the modal itself.

If you don't see your existing Ledger address(es), please try selecting "Ledger - Legacy (ETH)"

4. It's a bit more complex than just adding a new path and switching up the defaults though as the number that we iterate through on the path is changing as well, from m/44'/60'/0'/x to m/44'/60'/x'/0/0:

m/44'/60'/0'/0/0
m/44'/60'/1'/0/0
m/44'/60'/2'/0/0

So we will need to update how we derive for this specific path (but none of the others) as well.

[Arachnid]

@gre What possessed the Ledger team to pick an entirely new option, instead of one of the four or so existing ones used by other devices and wallets? The tower-of-babel around derivation paths was bad enough already!

Edit: Also, there's an open pair of EIP drafts (600 and 601) that define ethereum-specific derivation paths. Would you consider transitioning to them instead of another oddball Bitcoin-based path?

[gre]

@Arachnid

I think the main reasons was

• the derivation path is consistent across all other cryptocurrencies and is standard (following BIP44, so it's not something we invented).
• this offers more privacy because it's an hardened derivation
• (minor) only BIP44 seems to clearly state that you scan address in order, which does not seem the case for other choices? (MEW deliberately allow you to pick any address, not necessary "the next one")

is there any of the options that uses hardened derivation we were not aware?

[Arachnid]

the derivation path is consistent across all other cryptocurrencies and is standard (following BIP44, so it's not something we invented).

BIP44 doesn't really fit Ethereum very well. As a result, there's already several mutually incompatible interpretations of which component to increment. I'm sure the MEW folks could summarise existing options for you.

this offers more privacy because it's an hardened derivation

This is a nice benefit - but is it worth breaking compatibility with every other user of the scheme for it?

[SharonManrique]

Added to Asana

[cburgdorf]

We should make the old Ledger path available in the dropdown under Ledger - Legacy (ETH)

@tayvano I came here to open an issue about that but then found this one. Currently the derivation path that people used when they bought and set up a ledger a while back isn't listed anymore. This may confuse a lot of people who are trying to access there account with their seed phrase (which they shouldn't in the first place but still it happens)

[DavidBueno77]

@cburgdorf that would be me..

I have not been able to move my EOS tokens in time. Super dumb, I know.
Now, to move my eos, I need my ETH private key. I use MEW with ledger, so I dont have the private key..
I use https://iancoleman.io/bip39/ to create my keys fro my ledger seed, but I cant find the right adress.

I am confused on how to set it right.. I dont know the account nr of my eth adres for exampe, and now reading into these posts only confuse me more..

Sorry if this is the wrong place for these questions, new to github.. hi!

[tayvano]

@DavidBueno77 Please email us at [email protected] and we'll help you out! Much easier than github!

[ghost]

doesn't this page need an update too?
https://support.ledger.com/hc/en-us/articles/115005297709-Export-your-accounts

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[timbeiko]

@wtzb is there anywhere we can follow progress on this? Thanks!

[Mrtenz]

@timbeiko This is supported in the current version of MyCrypto. If you're using the legacy desktop application, you can access your Ledger Live adresses by specifying the derivation path manually (e.g., m/44'/60'/x'/0, where x is the account index in Ledger Live).

[timbeiko]

@Mrtenz yeah, I was able to do that. I was wondering if there are plans to add it as part of the default UI so you don't have to manually copy/paste the derivation path.

[Mrtenz]

@timbeiko We don't actively add new features to the current desktop application, but this will be fully supported on the replacement we are working on!

[arnetheduck]

Hi! I'm looking to sign a message with a ledger-live-derived address, but the "sign message" section of the web site does not appear to support "ledger live" derivation paths - what am I missing? Importing for sending and receiving eth works fine.

[ekkis]

The benefit of this is that, as we increment an "hardened" path so it's more "secure" in term of privacy

that sentence is malformed. I think it means to say The benefit of this is that we increment a "hardened" path so it's more "secure" in term of privacy

[ekkis]

The main change from your side is that, is as it's not a public derivation, you can't derive like you do, without the device, you will need to always ask the device to derive each address.

also broken. perhaps:

The main change from your side is that, as it's not a public derivation, you can't derive without the device. You will need to always ask the device to derive each address.

[ekkis]

because, as we follow BIP44, when scanning accounts is to stop at first account without transactions

it's hard to understand this language. I think it means:

because, as we follow BIP44, when scanning accounts we are supposed to stop at first the account without transactions

[gre]

@ekkis you are correct. I should have proofread myself a bit more. Let me know if you need more information or clarification.

[ekkis]

@ekkis you are correct. I should have proofread myself a bit more. Let me know if you need more information or clarification.

no worries. there are more corrections needed but I will finish proof-reading a bit later