Unable to discover accounts when they are not continuously used

[eshon]

From @hsanjuan:

There seems to be a bug in ledger live when adding more than 4 FIL accounts from one ledger. It starts derivating addresses using a new path and it also incorrectly stores new addresses (the 4th address generated already exists and the 5th address switched name with a previously generated one)

:link: zboto Link

[eshon]

@ainhoa-a - FYI - not sure how to file issues to the Ledger Live <> Filecoin integration

[emmanuelm41]

@eshon would it be possible to get the JSON logs the app gives you when there is a problem in the app? Or at least some screenshots of the problem? I have tested the app with 4 or 5 accounts and it worked locally in the past. Logs would help us a lot. Otherwise, I only can try to reproduce it again.

[hsanjuan]

@emmanuelm41 what are the derivation paths of the 5 first accounts you created on Ledger live?

The 5th account switches the derivation path for me, and no longer uses what lotus/glif use. So it is not possible to import more than 4 "glif" accounts.

[emmanuelm41]

Ledger Live is actually scanning on three different derivation schemes: Ledger Live, Glif and Grif legacy. In the three of them, what Ledger Live does is scanning one by one until it hits one account that has no funds on it. That account will be the "next one" it offers you to add (besides the previous ones that have txs on them). Ledger Live will start with Glif legacy, then gif and finally its own derivation scheme. Is it possible that is what happening to you?

[hsanjuan]

In my tests:

• Adding a first account with ledger live uses glif derivation paths m/44\'/461\'/0\'/0/0
• Adding a second account same m/44\'/461\'/0\'/0/1

At this point I sent money to m/44\'/461\'/0\'/0/2 and m/44\'/461\'/0\'/0/3. It discovered them and tagged the second, the third and the forth as "3rd party".

• Adding new account then uses a different derivation scheme. I can guess it scanned m/44\'/461\'/0\'/0/4 and saw 0 FIL and switched to its own scheme.

Per a previous test, It seems the discovery mechanism falls apart when it finds an account with 0 FIL (it will stop discovering on the Glif derivation paths and start with its own, so it is not possible to import accounts if some are unused in the middle).

IMHO compatibility would be better if it stuck to the glif/lotus derivation paths (it seems to start with them?). But otherwise scanning should be a bit more robust, not bailing out as soon as a 0 FIL address is found.

[hsanjuan]

I also had a problem where accounts got renamed when I created the 4th account and used its own derivation path (as it account settings were overwritten in the wrong slot), but I'm not sure if it can be reproduced.

[emmanuelm41]

@hsanjuan the mechanism is not failing. It is working as Ledger has planned. It will stop scanning accounts the moment it finds that the following account has not transactions on its history. I can be configured to look for 1, 2 or more accounts with empty history. That will make the process slower though. But again, this is not a bug, but an expected behavior.

[emmanuelm41]

I also had a problem where accounts got renamed when I created the 4th account and used its own derivation path (as it account settings were overwritten in the wrong slot), but I'm not sure if it can be reproduced.

Regarding this other comment, if you can share with us a screenshot to see what happened, it would be great. So far, the mechanism is done by Ledger, and it is working correctly for other chains. Glad to help if you can provide more info!

[hsanjuan]

@hsanjuan the mechanism is not failing. It is working as Ledger has planned. It will stop scanning accounts the moment it finds that the following account has not transactions on its history. I can be configured to look for 1, 2 or more accounts with empty history. That will make the process slower though. But again, this is not a bug, but an expected behavior.

If you have one account with 0, then the next ones will never be discovered even if they have funds. So yeah, discovery should probably look a little bit further. But ok...

I don't have any state from the previous issue, but must be unrelated.

[hsanjuan]

(I can't close this issue).

[emmanuelm41]

Thank you @hsanjuan for the feedback.Let us know if you find anything else. I will close the issue then!