Electron-cash: "cannot pair trezor" with Electron-Cash-4.1.0-fusion

Created on 5 Mar 2020  路  22Comments  路  Source: Electron-Cash/Electron-Cash

using Electron-Cash-4.1.0-fusion-1-74-g12dd3338e-x86_64.AppImage I cannot pair my trezor.

Traceback (most recent call last):
  File "/tmp/.mount_Electr481Czl/usr/lib/python3.6/site-packages/electroncash_gui/qt/util.py", line 949, in run
    result = task.task()
  File "/tmp/.mount_Electr481Czl/usr/lib/python3.6/site-packages/electroncash/wallet.py", line 2469, in sign_message
    return self.keystore.sign_message(index, message, password)
  File "/tmp/.mount_Electr481Czl/usr/lib/python3.6/site-packages/electroncash_plugins/trezor/trezor.py", line 62, in sign_message
    client = self.get_client()
  File "/tmp/.mount_Electr481Czl/usr/lib/python3.6/site-packages/electroncash_plugins/trezor/trezor.py", line 56, in get_client
    return self.plugin.get_client(self, force_pair)
  File "/tmp/.mount_Electr481Czl/usr/lib/python3.6/site-packages/electroncash_plugins/trezor/trezor.py", line 185, in get_client
    client = devmgr.client_for_keystore(self, handler, keystore, force_pair)
  File "/tmp/.mount_Electr481Czl/usr/lib/python3.6/site-packages/electroncash/plugins.py", line 878, in client_for_keystore
    client = self.force_pair_xpub(plugin, handler, info, xpub, derivation, devices)
  File "/tmp/.mount_Electr481Czl/usr/lib/python3.6/site-packages/electroncash/plugins.py", line 923, in force_pair_xpub
    'receive will be unspendable.').format(plugin.device))
electroncash.plugins.DeviceUnpairableError: Electron Cash cannot pair with your Trezor.

Before you request bitcoins to be sent to addresses in this wallet, ensure you can pair with your device, or that you have its seed (and passphrase, if any).  Otherwise all bitcoins you receive will be unspendable.

I verified passphrase is correct by using older, non-cashfusion version (tried many times)

bug hardware wallets observation required

All 22 comments

This also happens in master branch.

I tracked it down a little: in tag 4.0.13dev1 it's still working ok, in 4.0.13 the issue occurs.

Wow that's helpful. I'll try to reproduce here later and let you know. If you don't hear back from me in a few days... ping me again here!

Just curious what Linux version/distro are you on?

I think my issue is related to this. I cannot pair anymore my password protected Trezor wallets in 4.0.13. Those same wallets get paired fine with 4.0.11.

What I found out till now is that if I create a new Trezor wallet with 4.0.13 with the same Trezor password it creates DIFFERENT addresses than if I create it with 4.0.11. It doesn't matter if I choose m/44'/145'/0' or m/44'/0'/0' I'm never able to create the same BCH addresses with 4.0.13 that I got with 4.0.11.

I am still able to pair my 4.0.11 Trezor wallet that has NO password with 4.0.13. So the bug must have to do something with the implementation of the password in 4.0.13.

I'm using Linux Mint Debian (LMDE).

Edit: Just checked. The pairing with the Trezor still works fine with 4.0.12. So the bug was introduced with 4.0.13.

@darkbluelight thanks for digging in. Sounds like the same issue (I also use a passphrase, maybe some text encoding issue)

@cculianu I'm on arch linux. In case you need me to narrow the breaking change down to a single commit, I can do that with a little bit of time (O(ln(number of commits)) to be more specific ;-)). Also PING ;-)

If you could that would be helpful -- i'm a little backlogged so that would help @molecular !!

@molecular You would have to use git bisect -- you know how to use it right?

Start a git bisect like this:

git bisect start
git bisect bad v4.0.13
git bisect good v4.0.11

It should then tell you something like this:

Bisecting: 675 revisions left to test after this (roughly 10 steps)

This tells you how many revisions (changes) are between those two versions and an estimate of how many you will have to test to find the bad revision.

Now for every revision bisect stops at you have to test if the version works or not. So you need to set up a fresh python environment, start EC using it and check for the issue. When the current revision is good you exectute git bisect good and if it is bad you execute git bisect bad

Using this you should end up at the commit which introduced the issue in the minimum number of steps possible. When you do it should tell you something like ` is the first bad commit"

See here for more information: https://git-scm.com/docs/git-bisect

Thanks @EchterAgo for the bisect refresher, it's been a long time...

this commit that made things go sour: d6a4d28279bf522a89b3d923b017d6076000c1b9

d6a4d28279bf522a89b3d923b017d6076000c1b9 is the first bad commit
commit d6a4d28279bf522a89b3d923b017d6076000c1b9
Author: Calin Culianu <[email protected]>
Date:   Mon Feb 10 17:27:40 2020 +0200

    Refactor mnemonic.py; resurrect BIP39 seed generation

I didn't regenerate python env between steps, I hope that's not the issue.

Edit: I hope we don't have to keep that old mnemonic implementation around just for trezor?!?

@molecular thank you very much for taking the time to find the bug!
@EchterAgo thank you for your help with bisect!

@darkbluelight, well, I didn't "find the bug", just identified the commit that broke things.

From the looks of it I think it will probably quickly become apparent to @cculianu what the problem is when he sees the commit, though.

Yeah -- it's probably a crash in the plugin due to API changes. I could have sworn it was working and that I tested it but apparently I did not. I'll let you know what I come up with.

I'll also do some testing with Keepkey and Ledger.

Thanks @EchterAgo

this persists in 4.1.0-fusion-2 (which I assume is most recent fusion tag?) and also master.

@cculianu you said above I should ping you in case you forget this issue. Well: ping!

Sorry for forgetting to test this. So Keepkey and Ledger still work fine and I did test this using the Trezor emulator, but I fail to reproduce this. Using the official AppImage of both 4.0.12 and 4.0.13 I made new wallets for a password protected Trezor and received the same addresses. I tried with 2 different passwords. Maybe it is password specific? Anyone mind sharing the password they are using? Also, what firmware version are you using?

@EchterAgo thanks a lot for testing!

sorry, cannot share the passphrase. It has letters, numbers and some symbols, but nothing non-ascii or otherwise wild.

firmware is 1.8.3 (not the most recent, I admit)

If you're out of ideas, one thing I can think of doing myself is checking with those 2 appimage you mentioned instead of running from sources like I did with bisect?

Or maybe I should try updating firmware first?

upgraded firmware to 1.9.2, problem still occurs (EDIT: on master branch, works in 4.1.0, see below)

partly Good news...

I can open wallet and successfully enter passphrase in 4.1.0 but not in master.

I'm starting to get confused. Overview (firmware 1.9.2, trezor lib 0.11.2):

  • 4.0.13: DeviceUnpairableError when entering passphrase
  • 4.0.13-dev1: can open wallet, can sign message, cannot send tx (see other issue #1966)
  • 4.1.0: can open wallet, can sign message, cannot send tx (see other issue #1966)
  • master e1fe712b2: DeviceUnpairableError when entering passphrase
  • 4.1.0-fusion-2: DeviceUnpairableError when entering passphrase

with another trezor with really old firmware (1.6.3) and same seed I get this picture:

  • 4.0.13: DeviceUnpairableError when entering passphrase
  • 4.0.13-dev1: can open wallet, can sign message, can send tx
  • 4.1.0: can open wallet, can sign message, can send tx
  • master e1fe712b2: DeviceUnpairableError when entering passphrase
  • 4.1.0-fusion-2: DeviceUnpairableError when entering passphrase

so 4.0.13, master and 4.1.0-fusion-2 behave identically (DeviceUnpairableError) for both firmware versions I have available on hardware.
4.0.13-dev1 and 4.1.0 also behave identically (everything I test works) except that new other issue with the new firmware 1.9.2

EDIT: made that other issue: #1966
EDIT2: that master version I used was old (hadn't pulled), which added to my confusion a lot

Hmm. See if you can upgrade to firmware 2.0? (Not 2.3 -- that limits you to using only /145/ paths!)

I don't think I can upgrade to firmware 2.0. It's a "trezor one", not Model T. I used wallet.trezor.io to upgrade firmware and it says 1.9.2 is the newest.

Wonderful!!!

on master branch 292e860fc (I was on older commit earlier) everything works now with firmware 1.9.2 (didn't re-test the older 1.6.3).

Still confused what the issue actually was, though.

Thanks for all your help and digging in!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

imaginaryusername picture imaginaryusername  路  5Comments

EchterAgo picture EchterAgo  路  4Comments

tracyspacy picture tracyspacy  路  6Comments

markblundeberg picture markblundeberg  路  4Comments

ProfessorVenkman picture ProfessorVenkman  路  4Comments