Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What part of hsm_secret 2 lines to use? #2

Open
salenjak opened this issue Dec 6, 2023 · 5 comments
Open

What part of hsm_secret 2 lines to use? #2

salenjak opened this issue Dec 6, 2023 · 5 comments
Assignees

Comments

@salenjak
Copy link

salenjak commented Dec 6, 2023

Hi,

I am trying to test this tool to get XPRV from CLN on my Raspiblitz, but without success.

Can you please tell me what part of the hsm_secret have you use to get it work.

This is hsm_secret format I get (when decrypted):

00000000: x1x1 x1x1 x1x1 x1x1 x1x1 x1x1 x1x1 x1x1 .x.1.x.1.x.1.
00000010: x1x1 x1x1 x1x1 x1x1 x1x1 x1x1 x1x1 x1x1 1.x.1.x.1.1.x.

I have rised this is issue also here: raspiblitz/raspiblitz#4267

Thanks in advance

@dieqohc
Copy link
Owner

dieqohc commented Dec 6, 2023

Hi,

Well in this case you don't need to decrypt the hsm_secret before operating with it, what you need is to copy or move the file (make sure to make a backup of the file before) to the same directory of the repo you have downloaded and extracted.

As soon as the file is on the same directory you just have to run the recovery.py file and this should give you as a result the XPRV.

Also I have received the feedback already to make this guide step by step, because it doesn't seem to be that clear if you haven't interacted with a tool like this before, let me know if the short guide isn't clear enough for you either so can make it a priority.

@dieqohc dieqohc self-assigned this Dec 6, 2023
@salenjak
Copy link
Author

salenjak commented Dec 7, 2023

Hi dieqohc,

Thanks for answering. I have successfully extracted XPRV with your script.

In summary, I was pasting 2 lines of the hsm_secret hex backup from my password manager in the hsm_secret file in the folder with the recovery.py file.
But I didn't convert hsm_secret.txt file back into the binary hsm_secret 32 bytes format (xxd -r hsm_secret_hex.txt > hsm_secret).

There is only a problem with the derivation path. For start, my wallet have 9 Native Segwit UTXOs and 1 Taproot. When I imported XPRV in Sparrow wallet (m/* derivation path, Native Segwit), 4 of 9 UTXOs where listed as being sent to external addresses. When checking in the RTL-CLN wallet all 10 UTXOs are listed (9+1). So RTL obviously better manage derivation paths.

So, when I restore CLN wallet in the Sparrow I need to create 2 wallets with same XPRV, one for Native Segwit and one for Taproot and even then I still don't know what are derivation path of the 4 Native Segwit UTXOs that were created as a result of the channel force closure.

This can be a problem for a newbies because they can think that those 4 were penalty transactions or some bug and funds are sent to wrong address.

So when restoring in Sparrow wallet we will definitely need to create multiple wallets and know correct paths to find all UTXOs related to extracted XPRV.

So there is a path besides m/* that will show rest of the UTXOs. It must be included in "When importing the XPRV the derivation path for the funds is "m/*" which can be represented as "m/0"." message.

@dieqohc
Copy link
Owner

dieqohc commented Dec 7, 2023

I'm glad you can now see your funds.

And that's a bit confusing, the thing is I don't have a way to test this as I don't have core-lightning anymore, but installing RTL on my LND instance and checking on my UTXOs info it doesn't show anything regarding the derivation path of foreclosure channels (i haven't had any so far), so i think you should look for support in this case by the RTL community or devs, and I will include this in the documentation.

Also, there is a couple of questions that come to my mind, like...

  1. The separation of this UTXOs in native segwit and taproot are given bc you sent funds on a native segwit address given by c-lightning and the taproot were given by another software like RTL?
  2. Just by choosing taproot and DP m/* you were able to see your taproot UTXO too? Just asking to make sure the funds arec located in the same index and add this info to the documentation for clarification ASAP.

Edit: external chain is m/0'/0' (account 0, external addresses). For the internal chain (change addresses), the default derivation path is m/0'/1' (account 0, internal addresses). Please check these d-paths.

@salenjak
Copy link
Author

salenjak commented Dec 8, 2023

1.The separation of this UTXOs in native segwit and taproot are given bc you sent funds on a native segwit address given by c-lightning and the taproot were given by another software like RTL?

9/10 channels where closed in period when Taproot wasn't used as default by CLN. So when force closed (v23.05 broken a lot of wallets because msat prefix is removed. In my case it messed with CLBOSS plugin) they defaulted on the Native Segwit path. The Taproot UTXO was a channel opened a few months ago in CLN v23.08 and when closed by me (plan to run node on better hardware then rpi4) it defaulted on the Taproot address.

2.Just by choosing taproot and DP m/* you were able to see your taproot UTXO too? Just asking to make sure the funds arec located in the same index and add this info to the documentation for clarification ASAP.

Yes. Because Sparrow wallet let you choose script type when you create wallet. So, select new wallet, paste xprv, enter m/* as a path, and on the next screen select script type from the selectbox.

Regarding DPs:

My CLN wallet = 10 UTXOs (9 NativeSegwit, 1 Taproot)

Sparrow wallet m/* + NativeSegwit selected = 5/9 UTXOs available, 4 sent to external address
Sparrow wallet m/0'/0' + NativeSegwit selected = nothing
Sparrow wallet m/0'/1' + NativeSegwit selected = nothing
Sparrow wallet m/* + Taproot selected = 1/1 UTXO

@dieqohc
Copy link
Owner

dieqohc commented Dec 9, 2023

Hmmmmm my interaction with c-lightning was so brief i didn't even had the opportunity to try any plugins (maybe it had to do with running a full node with the RPi 4 and 2GB RAM), anyways I will have to look further on the code of c-lightning to check if I find this info on the movement of funds to a certain derivation path.

Also, maybe try with m/1? I know at this point is guessing but wouldn't make much sense moving the funds with a big path gap between them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants