nostr:nprofile1qqs0zuj4s6jq9sr2ajqc69rc53d25rwpd3afcjrfm97r2qek69hcuscpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgawaehxw309aex2mrp0yhx6at5d9h8jampd3kx2apwvdhk6tcgjgr05 May I ask why it is so difficult to find the XPRV or BIP32 of the on-chain wallet that funds channels? Is it a security minded outlook? Having the ability to see the master seed for back up purposes OUTSIDE of the Lightning channel states is of use to me and yet I find myself having to go into command-line and decrypting hsm secrets.

I love Core Lightning, and LND's Azeed is no better here. I am just curious if this was a conscious choice.

Reply to this note

Please Login to reply.

Discussion

Obviously it was a conscious choice. I've had numerous people yell at me for asking why the heck can't we have a standardized BIP39 back up method.

It's not about BIP39. BIP32 is fine, I just want to access it without doing crazy command-line gymnastics. My standard Bitcoin wallet offers a way to see my XPRV without a bunch of hoops. That's all I'm saying.

You can't take an existing secret and express it as BIP-39. This is a huge problem :( You have to start with a BIP-39 in the first place.

You can use BIP-93, but who supports that?

We do have a BIP32 for the onchain funds, so you could have an external watcher. We should add an xpub to getinfo: want to file an issue requesting it for next release?

It won't cover *all* your funds, since unilateral closes go to weird time locked addresses, but it would cover most.

We don't generally give out privkeys: they stay in the hsm daemon for design reasons (hence the external tool to extract them).