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
* oneshot channels instead of custom promises
* Future instead of handle_dispatch
* Even less copying
* Those explicit waits were a mistake, thanks, @tomusdrw
* No more unsafe polling
* Test for the new `is_done()` method
* Mark Futures as `#[must_use]`
* Solve most compilation warnings
* `try_ready!` is more ideomatic
* Turn spaces into tabs
* Documentation and visibility improvements
* Minor code style improvements
* Make Futures run on an explisit reactor
* Another round of code style issues
* Simplify ConfirmationReceiver type
* Flatten ConfirmationOutcome into a plain Result type
* Get rid of a separate `pending` set, it was a stupid idea
* Clarify `add_request` docs
* No need to reduce the scope of the mutex here
Fredrik Harrysson
Marek Kotewicz
GitLab Build Bot
Tomasz Drwięga
Dmitry Kashitsyn
Arkadiy Paronyan
Kirill Pimenov
Tomasz Drwięga
Afri Schoedon