6

I read a part of Ledger nano S documentation (including HD Wallet and BIP39/BIP44 derivation path, and BOLOS system, that you can find at https://ledger.readthedocs.io/en/latest/background/introduction.html). I also looked at different sources, either to better understand an error I could have made, or some code I could reuse to make a better script to test the values and find my PKH: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#use-cases https://iancoleman.io/bip39/ I did not find better than bruteforcing until now (the security the ledger is offering does force that only solution, which is ok).

  1. In the beginning, I jumped on the first tezbox version that allowed linking with my Ledger Nano S. At some point I deleted the data in the chrome navigator and the wallet at the same time. I have tried since then to get access to my xtz. I know the tz1 PKH and I have my Ledger Nano S.
  2. I brute-forced the path, 44'/1729'/0'/0' modifying incrementally the 2 last value in the Derivation Path, without success.

So my questions are:

  1. Was there a change in previous version of the tezos-client that could affect the creation of new PKH (the derivation tree for HD Wallet), that would disrupt my attempts to brute-force my way using tezos CLI?
  2. Question addressed to tezbox team: did you change something, was there a bug in the first versions published which could affect the derivation of PKH and preventing me to generate my PKH where my funds are locked on the current version of tezbox? Was there a possibility, for example, to modify the PATH, including 44'/1729', corrected afterwards?

I want to make very clear that I don't want to blame anyone else (but me), but merely have information that would be crucial to my investigation to access my xtz tokens again.

Thanks a lot in advance for your answers!

EDIT (05/06/2021):

  1. It looks like I lost access to this account - I've not, so far, found back access to this address. The address has not changed, the funds,are still there.

  2. I found (through another project's searches) those information I had not at the time that lead me to think that a likely scenario is a parsing problem between the 3 elements (listed above and below) of the BIP39/BIP44 HD PATH - I know it is not directly linked to tezos, and maybe clef dependency was never in the picture of tezos-ledger app, but the latter I don't know:

https://github.com/MyCryptoHQ/MyCrypto/issues/2070

https://github.com/ethereum/go-ethereum/pull/21757 https://github.com/ethereum/go-ethereum/issues/21592 https://github.com/ethereum/go-ethereum/pull/21517

For clarity: I used tezbox (early, when the feature to link it to ledger nano was made possible - funds were transferred in November 2018).

There is still no doubt that I can regain access to my funds as long as information is brought to me that could help me understand the potential side-effects of ledger legacy bip HD derivation path on the tezbox frontend and the ledger tezos application of that time- and if any inconsistencies were observed at the time, including tezbox interactions with tezos ledger app.

A good way forward would for me to be able to test with the tezos ledger application and command line tezos-client the different inputs (addresses with different HD Paths schemes (meaning potentially no /0h or /0' but plain /0).

I would, again, appreciate any elements brought to me that could help (not already mentioned at the time). Thank you in advance.

Improve this question
7
  • hi, welcome to tezos stack exchange! please provide link of the docs you are referring to. It will help understand better, thanks!
    – Ezy ♦
    Apr 14 '19 at 18:55
  • H, you say you tried to brute force the last 2 parts of the derivation path, but did you try them with the 3 ≠ curves?
    – Seb Mondet
    Apr 14 '19 at 19:41
  • Hi Seb, I assumed tezbox and tezos application used by default the ed25519 curve scheme. Do you think it could be otherwise?--because I did not change this setup. I will look into that to check if it can have been changed on the application side.
    – tndnz
    Apr 15 '19 at 14:22
  • @Ezy, thank you. BTW I wanted to apologize before for the editing of a post which was not mine, but as a new user I could not answer or comment. It was really more the result of rush to try to get an answer, but not intended to bypass rules or pollute discussions. Sorry for that.
    – tndnz
    Apr 15 '19 at 14:25
  • Recently I could not access my Ledger Nano S via TezBox. The path (44'/1729'/0'/0') seems wrong. I could access it using Galleon, which uses a different path: 44'/1729'/0'/0'/0'. Not sure if this is specific to my Ledger or not, but I hope it helps.
    – palthk_on
    Apr 18 '19 at 14:33
1

It is most likely that your address is the root path - I recommend trying the import command without the derivation path. tezos-client did change a few months ago: it used to show 6 import command options - the first three were the 3 root paths (1 for each signing cuve) and 3 with a derivation path, i.e. /0'/0'

I suspect you'll find your missing address using tezos-client import secret key ledger_yourstruly "ledger://adjective-animal-adjective-animal/ed25519/"

Improve this answer
4
  • Thanks, but no, I tried already this manually and through my bruteforce small script. But I do take note of the change that you mention.
    – tndnz
    Apr 23 '19 at 16:00
  • 1
    Ok, I have one more thing that may help. Unfortunately due to bash, entering the path with/without quotes changes the derived address. We are making adjustments to prevent this, but in the meantime, I recommend trying both. For instance: ./tezos-client import secret key <name> "ledger://<alltheanimalstuff>/secp256k1/0'/0'" results in a different PKH than ./tezos-client import secret key <name> ledger://<alltheanimalstuff>/secp256k1/0'/0'
    – mikereinhart
    Apr 24 '19 at 14:12
  • I am going to try agagin my bruteforce script to include this. I will keep you updated if it succeeds. Thanks a lot you for your help.
    – tndnz
    Apr 25 '19 at 15:19
  • Let us know how it goes!
    – mikereinhart
    Apr 30 '19 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.