Model One - TrezorConnect.getAccountInfo() produces incorrect address

Third party wallets
,
1

Good day,

I’m attempting to integrate Trezor Connect into an Electron App. I have both Model T and One devices. Calling TrezorConnect.getAccountInfo() “using path” I’m able to retrieve the correct address on Trezor Model T, but not on the Trezor One.

My code:

TrezorConnect.getAccountInfo({
  coin: "tgor",
  path: "m/44'/1'/0'/0/0",
});

I’ve also tried:

  • TrezorConnect.getAccountInfo() “using discovery”. This works on Trezor Suite, Metamask
  • I’ve tried copying, with no success on either device, MetaMask/eth-trezor-keyring which uses TrezorConnect.getPublicKey() and derives addresses using npm hdkey, npm @ethereumjs/util. Here’s what that code looks like:
let hdKey = new HdKey();

const addressFromIndex = (pathBase, i, _hdKey) => {
  const dkey = _hdKey.derive(`${pathBase}/${i}`);
  const address = ethUtil.publicToAddress(dkey.publicKey, true).toString("hex");
  return ethUtil.toChecksumAddress(`0x${address}`);
};

TrezorConnect.getPublicKey({ path: "m/44'/1'/0'/0/0", coin: "tgor" }).then(
  (response) => {
    hdKey.publicKey = Buffer.from(response.payload.publicKey, "hex");
    hdKey.chainCode = Buffer.from(response.payload.chainCode, "hex");

    response.hdKey = hdKey;
    response.address = [
      addressFromIndex("m", 0, hdKey),
      addressFromIndex("m", 1, hdKey),
      addressFromIndex("m", 2, hdKey),
      addressFromIndex("m", 3, hdKey),
    ];
  }
);

Additional information:

  • Both addresses have TGOR funds.
  • I’ve tried using a different derivation path m/44'/60'/0'/0.

Thanks!

1 Like
2

Edit: This works on Trezor Suite when using Trezor Connect explorer

1 Like
3

what does Trezor One give you?

can you reproduce the problem with all all all... (12x) seed?

1 Like
4

Trezor One gives me an address, but not the one displayed in Trezor Suite.

Just tested all all all with both devices and this is the result:

One:
ethereumGetAddress - 0xe6ff0Da3BB09793825d0fB21c3373916A832F234
Trezor suite - 0x7de62F23453E9230cC038390901A9A0130105A3c

Model T:
ethereumGetAddress - 0x7de62F23453E9230cC038390901A9A0130105A3c
Trezor suite - (same as above)

Side-note: Trezor One always prompts with “Test legacy address #1” when calling ethereumGetAddress

1 Like
5

The results are the same for TrezorConnect.getAccountInfo() on descriptor property.

1 Like
7

I cannot reproduce the problem. I always see 0x7de62... with both Trezor T and Trezor One. I tried a couple variations on the derivation path but can’t get to see 0xe6ff... anyhow.

Please make sure that both devices actually have the same seed, or that a passphrase doesn’t get mixed in somehow. Please check whether you’re also getting different Bitcoin addresses.

1 Like
8

Changing the seed would be redundant as both devices (One and Model T) display:
0x7de62F234... inside Trezor Suite, confirming that seeds are the same? I have wiped both devices again anyway.

Below is a full output of addresses received between Trezor Suite & TrezorConnect.${method} for both devices using seed all all all with no passphrase:

Trezor Suite:

These are the addresses seen in Trezor Suite.

Account Trezor One Model T Equal
Ethereum Goerli #1 0x7de62… 0x7de62… :white_check_mark:
Etherium #1 0x73d03… 0x73d03… :white_check_mark:
Bitcoin #1 bc1qannf… bc1qannf… :white_check_mark:

Below are the method calls on TrezorConnect and their responses.

1. TrezorConnect.ethereumGetAddress({ coin: "tGOR", path: "m/44'/60'/0'/0/0" })

This yielded no matches for either devices

2. TrezorConnect.ethereumGetAddress({ coin: "tGOR", path: "m/44'/1'/0'/0/0" })

2.1 Trezor One

payload.address Expected Match
0xe6ff0… 0x7de62… :x:

2.2 Model T

payload.address Expected Match
0x7de62… 0x7de62… :white_check_mark:

3. TrezorConnect.ethereumGetAddress({ coin: "ETH", path: "m/44'/60'/0'/0/0" })

3.1 Trezor One

payload.address Expected Match
0x58439… 0x73d03… :x:

3.2 Model T

payload.address Expected Match
0x73d03… 0x73d03… :white_check_mark:

4. TrezorConnect.ethereumGetAddress({ coin: "ETH", path: "m/44'/1'/0'/0/0" })

This yielded no matches for either devices

5. TrezorConnect.getAddress({ coin: "BTC", path: "m/84'/0'/0'/0/0" })

5.1 Trezor One

payload.address Expected Match
bc1qep9z… bc1qannf… :x:

5.2 Model T

payload.address Expected Match
bc1qannf… bc1qannf… :white_check_mark:

Additional:

  • I’m using Trezor Bridge
  • I’m running TrezorConnect.init() in the main process of Electron (Similar to NodeJS context) and using IPC to communicate with my UI.
  • @trezor/connect v9.0.6

Hopefully the above clears up any questions you might have concerning my issue. If the above methods are incorrect or there is something not being done correctly, could you please point me in the right direction. Thanks in advance!

Side note: I tested a transfer on Bitcoin #1 account and it was immediately transferred out. I knew the risks in sending it there.

1 Like
9

Right, I forgot about that part. That would seem to indicate the same seed, but with Trezor Connect, all the results are different, indicating that the problem is systemic somehow.

So there’s basically three options as to what might be going on:

  1. a passphrase somehow gets used when running Model One through Trezor Connect in your app, but not in Suite.
    Just to confirm, is the firmware up to date? Your Trezor should be showing a passphrase on screen if you use it. So if you don’t see the “confirm passphrase” screen, we can mostly rule this out. (Make sure that you unplug and replug the Trezor, to clear the internal session cache, and that no other app uses a passphrase while you’re testing this.)
  2. something is messing with the communication, either changing the derivation paths on the way in, or changing the results on the way out.
  3. there is a third Trezor with a different seed that gets called instead of your testing Trezor One unit.

I recently published this script that emulates Trezor Bridge. You can try running it instead of Trezor Bridge and observing the decoded communication. In the output, you would see the difference between calls to/from Trezor in the TT and T1 case – or in T1 + Suite vs T1 + your app.

1 Like
10

@matejcik

but with Trezor Connect, all the results are different, indicating that the problem is systemic somehow.

In each case the derivation-path and/or coin and/or method is different, so different results are expected.

For 100% clarity on my issue: TT is doing exactly what I expect it to do. T1 is not.

I’ll give your script a bash and see if it points to anything. Seams strange that it would happen on T1 and not TT.

1 Like
11

I’m going to close this. Re-installing Trezor Bridge and/or updating Python resolved my issue. Thanks @matejcik for your help, much appreciated.

1 Like