This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
Parity and MEW Trezor hardware wallet derivation path don't match #6811
Labels
F2-bug 🐞
The client fails to follow expected behavior.
M4-core ⛓
Core client code / Rust.
P0-dropeverything 🌋
Everyone should address the issue now.
Milestone
Comments
Sounds like a MEW issue. @folsen please confirm ;) |
5chdn
added
M4-core ⛓
|
Investigating this further, I can't actually really tell who's right or wrong here. But it definitely seems like MEW is adding a If you select the derivation path for Ledger in the MEW UI, you get the Parity-derived address for the Trezor. This address does indeed correspond to the output from Would be good if we could get a comment from someone at MEW about this. It would obviously be very preferable if we both derived the same. EDIT: I see now why it's adding a |
folsen
added a commit
that referenced
this issue
Oct 18, 2017
While the standard defined by Trezor as the default derivation path here https://blog.trezor.io/trezor-integration-with-myetherwallet-3e217a652e08 says that it should be `m/44'/60'/0`, in practice they don't have an implementation of a wallet for Ethereum themselves and refer customers to MEW. MEW has a custom implementation of the path derivation logic that allows them to generate multiple addresses by essentially adding `/0`, `/1` etc to the path. In my initial implementation of Trezor I didn't take this into consideration unfortunately and just used the keypath that Trezor themselves recommended. However, given that it's seemingly standard practice to append `/0` for a "sub-address" (and this is what we've done for Ledger as well) it seems like a mistake on my part to not take that into consideration. Unfortunately, anyone who has used their Trezor device with Parity previously would now see a different address when they connect the Trezor device the next time. The only way they would have to access the old address is to use an old version, or by going through MEW and selecting the Ledger keypath. Also see #6811
5chdn
added
F2-bug 🐞
|
The reason I found this is because when I first started using Trezor I
couldn't match the default MEW address with sample docs in Trezor.
Clicking the default MEW derivation path box, or the custom derivation path
with the same path filled in generates different addresses.
If you use the MEW UI and put a custom path of:
m/44'/60'/0'/0
It indeed matches Trezor. If you click on the MEW default derivation path
box which "displays"
m/44'/60'/0'/0
It seems it actually uses:
m/44'/60'/0'/0/0
This means the default MEW UI is implemented inconsistently or at the very
least the labeling is misleading.
…On Wed, Oct 18, 2017, 06:15 Fredrik Harrysson ***@***.***> wrote:
Investigating this further, I can't actually really tell who's right or
wrong here. But it definitely seems like MEW is adding a /0 to any
derivation path.
If you select the derivation path for Ledger in the MEW UI, you get the
Parity-derived address for the Trezor. This address does indeed correspond
to the output from trezorctl ethereum_get_address -n "m/44'/60'/0'/0"
like @mirage007 <https://github.com/mirage007> posted. However in the MEW
UI it's saying the path that it's using is m/44'/60'/0', so it does look
like it's adding a /0 to the end of every path. I don't know why that
would be. According to what I can read from the "standard" it shouldn't be
added.
Would be good if we could get a comment from someone at MEW about this. It
would obviously be very preferable if we both derived the same.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6811 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABnhQuRBg06UxXHrP_S5qT5l3AvKhGiWks5stc_GgaJpZM4P8_Cg>
.
|
|
@mirage007 Indeed I think the labeling is misleading or confusing. What they show is "the base path" upon which they build the actual address path. But it's not "the path" used to derive the address. However, it makes sense in the context of wanting to generate multiple sub-addresses to use the documented address as the base path to build further paths on. |
|
I guess that just means we are actually not matching MEW in terms of
addresses. If the intent is to do so, it seems we should make:
m44'/60'/0'/0/0 the default. And also probably put a ticket on MEW about at
least changing the language?
…On Wed, Oct 18, 2017, 08:26 Fredrik Harrysson ***@***.***> wrote:
@mirage007 <https://github.com/mirage007> Indeed I think the labeling is
misleading or confusing. What they show is "the base path" upon which they
build the *actual* address path. But it's not "the path" used to derive
the address. However, it makes sense in the context of wanting to generate
multiple sub-addresses to use the documented address as the base path to
build further paths on.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6811 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABnhQjpkHiZflxBRz0ahPQSiBi_rzRRUks5ste57gaJpZM4P8_Cg>
.
|
|
@mirage007 see #6815 |
arkpar
pushed a commit
that referenced
this issue
Oct 19, 2017
While the standard defined by Trezor as the default derivation path here https://blog.trezor.io/trezor-integration-with-myetherwallet-3e217a652e08 says that it should be `m/44'/60'/0`, in practice they don't have an implementation of a wallet for Ethereum themselves and refer customers to MEW. MEW has a custom implementation of the path derivation logic that allows them to generate multiple addresses by essentially adding `/0`, `/1` etc to the path. In my initial implementation of Trezor I didn't take this into consideration unfortunately and just used the keypath that Trezor themselves recommended. However, given that it's seemingly standard practice to append `/0` for a "sub-address" (and this is what we've done for Ledger as well) it seems like a mistake on my part to not take that into consideration. Unfortunately, anyone who has used their Trezor device with Parity previously would now see a different address when they connect the Trezor device the next time. The only way they would have to access the old address is to use an old version, or by going through MEW and selecting the Ledger keypath. Also see #6811
arkpar
pushed a commit
that referenced
this issue
Oct 20, 2017
While the standard defined by Trezor as the default derivation path here https://blog.trezor.io/trezor-integration-with-myetherwallet-3e217a652e08 says that it should be `m/44'/60'/0`, in practice they don't have an implementation of a wallet for Ethereum themselves and refer customers to MEW. MEW has a custom implementation of the path derivation logic that allows them to generate multiple addresses by essentially adding `/0`, `/1` etc to the path. In my initial implementation of Trezor I didn't take this into consideration unfortunately and just used the keypath that Trezor themselves recommended. However, given that it's seemingly standard practice to append `/0` for a "sub-address" (and this is what we've done for Ledger as well) it seems like a mistake on my part to not take that into consideration. Unfortunately, anyone who has used their Trezor device with Parity previously would now see a different address when they connect the Trezor device the next time. The only way they would have to access the old address is to use an old version, or by going through MEW and selecting the Ledger keypath. Also see #6811
arkpar
added a commit
that referenced
this issue
Oct 20, 2017
* Tweaked snapshot sync threshold * Change keypath derivation logic (#6815) While the standard defined by Trezor as the default derivation path here https://blog.trezor.io/trezor-integration-with-myetherwallet-3e217a652e08 says that it should be `m/44'/60'/0`, in practice they don't have an implementation of a wallet for Ethereum themselves and refer customers to MEW. MEW has a custom implementation of the path derivation logic that allows them to generate multiple addresses by essentially adding `/0`, `/1` etc to the path. In my initial implementation of Trezor I didn't take this into consideration unfortunately and just used the keypath that Trezor themselves recommended. However, given that it's seemingly standard practice to append `/0` for a "sub-address" (and this is what we've done for Ledger as well) it seems like a mistake on my part to not take that into consideration. Unfortunately, anyone who has used their Trezor device with Parity previously would now see a different address when they connect the Trezor device the next time. The only way they would have to access the old address is to use an old version, or by going through MEW and selecting the Ledger keypath. Also see #6811
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Before filing a new issue, please provide the following information.
Your issue description goes here below. Try to include actual vs. expected behavior and steps to reproduce the issue.
This relates to issue #4500 .
I just plugged in a trezor and it asked me to authenticate with pin in the Parity UI. Upon authentication, I see an account pop up, however the public address doesn't match that of MEW.
Using the Trezor command line, I manually compared the path of the trezor wallet by running:
trezorctl ethereum_get_address -n "m/44'/60'/0'/0"This matches the address of the Parity Wallet. However, when I run the Trezor via MEW integration, the first wallet that shows up seems to be generated from the below:
trezorctl ethereum_get_address -n "m/44'/60'/0'/0/0"Not sure where is the best place to put this, but at least I would throw it out there, given this is a new feature perhaps it's better to synchronize sooner rather than later.
The text was updated successfully, but these errors were encountered: