Ability to import a wallet from a root_xsk key

[benma]

Currently, one can import a hot wallet from a mnemonic seedphrase or a secret.key file.

In addition, it would be great to be able to import from a root_xsk... key. See How to generate a root private key (root.xsk) at https://github.com/input-output-hk/cardano-addresses/

Alternatively (maybe easier) would be to add support for importing a acct_xsk key, typically the account extended private key at m/1852'/1815'/0'.

This would make the wallet a flexible tool for recovery, e.g. for recovering a Ledger if the device is lost, as Ledger performs a different derivation of the root_xsk key than Adalite/Daedelus/etc.

I have not found much information about what the secret.key is supposed to contain or how to create one. Is there documentation about it somewhere? Possibly it would already be possible with this file if it can contain acct_xsk or root_xsk keys.

If this is not possible via the secret.key file, would you be open to adding support for this or accept a PR? I'd be happy to provide one.

[MichalPetro]

Hi,

we dont plan to do this but we can consider accepting a PR for this, what do you think @refi93 ?

[refi93]

@MichalPetro Sure we can consider it 👍

If by secret.key you mean the json key export file we have in Adalite, AFAIK there's no formal documentation and it was reverse-engineered from an early development version of Daedalus that had it, the relevant code is here: https://github.com/vacuumlabs/adalite/blob/develop/app/frontend/wallet/keypass-json.ts and here are tests for it: https://github.com/vacuumlabs/adalite/blob/develop/app/tests/src/keypass-json.js - the file basically contains the encrypted root secret key together with information about what derivation scheme to use (icarus vs pre-icarus) so there should be a way to transform root_xsk to it, though it's probably easier and more user-friendly to just extend the parsing on Adalite's side to recognize such key in a file has been supplied instead of our format, having cross-compatibility with cardano-addresses' root_xsk format

[benma]

Thanks guys, this is great. I will open a PR for this in due time.

The file basically contains the encrypted root secret key together with information about what derivation scheme to use (icarus vs pre-icarus) so there should be a way to transform root_xsk to it,

If it contains the root secret key as in, the mnemonic words (or the equivalent bytestring they encode) plus the derivation style to get to the BIP32 root key, then I am afraid it would not be possible. Can't go from the BIP32 root back to the phrase, as it is a one-way derivation (hashing).

If on the other hand it contains the BIP32 root key (root_xsk extended private key after the derivation from the mnemonic words), it would work.

In any case, having a separate tab to unlock using a root_xsk string should be straight forward and way more user friendly than an intermediate step through a key file.

[refi93]

In any case, having a separate tab to unlock using a root_xsk string should be straight forward and way more user friendly than an intermediate step through a key file.

Actually, I would rather not clutter the UI with further options, and reuse the "keyfile" option for that for now. Given the cardano-addresses tool is command-line based, outputting the root_xsk into a file as-is to then be picked up by our keyfile parser should be rather straightforward. We can think of better UX later on, but I think this could already be good enough

[benma]

Given the cardano-addresses tool is command-line based, outputting the root_xsk into a file as-is to then be picked up by our keyfile parser should be rather straightforward.

To clarify: do you mean that the keyfile in this case could contain only the root_xsk string and nothing else, and the parser could recognize that? That would be a good solution too. Maybe an option could also be to look at the filename extension. If .xsk, then parse the contents expecting a root_xsk string.

[refi93]

do you mean that the keyfile in this case could contain only the root_xsk string and nothing else, and the parser could recognize that?

Yes, that's what I meant