What is the extended private key in WIF format for? BIP32 root key (WIF)

[Forsyth Jones]

There is a way to convert an extended root private key to WIF format. Some tools do this, but I haven't found any use cases yet. Can it be used to recover the same wallet calculated by the extended private key? If not, what is its use?



I don't know of any wallet or tool that restores or derives addresses from a wallet using only the extended private key in WIF format, except for Bitcoin Core in the legacy wallet format.

Remember that an extended private key in WIF format is also a single common private key, so it can derive a common address.

In my opinion, if it's possible to restore a wallet using the WIF extended private key, it'd be much more practical to use an xpriv to restore, as it's an additional option.

[Charles-Tim]

The private key that starts from 05, K or L are referred to as wallet import format (WIF). They are private keys that a single address is derived from. So in HD wallet, they are child keys that generate their responding addresses.

BIP32 Root Key generates child keys while the child keys generate their corresponding addressed. It is the BIP32 which was used before BIP44 and others. BIP32 defines the path to HD wallet.

You can use it on Electrum.

[Forsyth Jones]

The private key that starts from 05, K or L are referred to as wallet import format (WIF). They are private keys that a single address is derived from. So in HD wallet, they are child keys that generate their responding addresses.

BIP32 Root Key generates child keys while the child keys generate their corresponding addressed. It is the BIP32 which was used before BIP44 and others. BIP32 defines the path to HD wallet.

You can use it on Electrum.

Thank you.

I would also like to know if it is possible to convert an extended private key in WIF format to xpriv. If so, what tool or code allows you to do this?

We know that it is possible to convert an xpriv to WIF format.

[Charles-Tim]

I would also like to know if it is possible to convert an extended private key in WIF format to xpriv. If so, what tool or code allows you to do this?

It is like asking if a leave can result to a tree. It is a tree that can result to leaves.

So that is not possible. I do not know how to explain this better than to tell you to read the mastering bitcoin chapter 4 which discussed about keys, addresses and wallet.

https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch04.html

[odolvlobo]

You answered your own question. It is used to set/restore the seed value for a Bitcoin Core HD wallet. The BIP32 Root WIF holds the 256-bit seed. It is not an extended key. The extended keys are derived from it.

[Forsyth Jones]

I would also like to know if it is possible to convert an extended private key in WIF format to xpriv. If so, what tool or code allows you to do this?

It is like asking if a leave can result to a tree. It is a tree that can result to leaves.

So that is not possible. I do not know how to explain this better than to tell you to read the mastering bitcoin chapter 4 which discussed about keys, addresses and wallet.

https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch04.html

I think you haven't gotten my point yet, the point here is that it is possible to generate an HD wallet, that is, derive receiving and change addresses using a single WIF key as an HD seed, the only wallet that did this was Bitcoin Core.

According to this post, Achow explains that in Bitcoin Core (bdb - legacy) the hdseed (WIF-key) is used to derive the extended private key (root master key) and then generate new keys using the new seed. Bitcoin Core used the BIP32 method to generate the master private key from a seed, the seed used was a WIF private key and not the common mnemonic in BIP39.

Today with the new descriptor format, this method is no longer necessary to derive an HD wallet using the WIF private key with the sethdseed command.

You answered your own question. It is used to set/restore the seed value for a Bitcoin Core HD wallet. The BIP32 Root WIF holds the 256-bit seed. It is not an extended key. The extended keys are derived from it.

I see, so why in the bitcoin core dumpfile, both the WIF key (which produces the keys from the WIF key seed value) and the xpriv master private key, but both generate the same keys?

I always thought that the WIF private key that contains the value hdseed=1 represented the same value as the xpriv, just converted to WIF.

[nc50lc]

There is a way to convert an extended root private key to WIF format. Some tools do this, but I haven't found any use cases yet.
Can it be used to recover the same wallet calculated by the extended private key? If not, what is its use?

I don't think that there will be a backup use-case for master/extended private keys that's converted to WIF.
Because the conversion practically stripped its "chain code" which is essential when deriving child (extended) keys of it.

For your legacy Bitcoin Core example, that was the "HDSeed" which isn't the 'master private key' nor 'extended private key'.
That is the "seed byte sequence" where the master private key is computed from.

[NotATether]

I don't think that there will be a backup use-case for master/extended private keys that's converted to WIF.
Because the conversion practically stripped its "chain code" which is essential when deriving child (extended) keys of it.

For your legacy Bitcoin Core example, that was the "HDSeed" which isn't the 'master private key' nor 'extended private key'.
That is the "seed byte sequence" where the master private key is computed from.

What is feasible is the backing up the seed phrase along with all of the derivation paths that the user would use, possibly in a compressed format (as in, using GZIP or something like that).

In the case of a regular wallet where the only variations in the derivation paths are the index and change numbers, then this can be reduced to just writing a depth for each of the primary (0) and change (1) indices.

No extended private key backups required.

[Forsyth Jones]

I don't think that there will be a backup use-case for master/extended private keys that's converted to WIF.
Because the conversion practically stripped its "chain code" which is essential when deriving child (extended) keys of it.

For your legacy Bitcoin Core example, that was the "HDSeed" which isn't the 'master private key' nor 'extended private key'.
That is the "seed byte sequence" where the master private key is computed from.

What is feasible is the backing up the seed phrase along with all of the derivation paths that the user would use, possibly in a compressed format (as in, using GZIP or something like that).

In the case of a regular wallet where the only variations in the derivation paths are the index and change numbers, then this can be reduced to just writing a depth for each of the primary (0) and change (1) indices.

No extended private key backups required.

I also think that backup and restore via mnemonic is the most practical, but when you say about compressed format, what do you mean exactly? Or are you talking about saving the descriptor?

In some wallets, at the time of restoration they already scan all possible derivation paths to identify UTXO (e.g. electrum), but just in case I recommend that you save at least the fingerprint and the derivation path, although most wallets use the standard path BIP44, 49, 84, etc.

[nc50lc]

I don't think that there will be a backup use-case for master/extended private keys that's converted to WIF.
Because the conversion practically stripped its "chain code" which is essential when deriving child (extended) keys of it.

What is feasible is the backing up the seed phrase along with all of the derivation paths that the user would use, possibly in a compressed format (as in, using GZIP or something like that).

I also think that backup and restore via mnemonic is the most practical, but when you say about compressed format, what do you mean exactly? Or are you talking about saving the descriptor?

He already provided an example inside the parenthesis which is "GZIP".
It's  similar to programs like "7Zip" or "WinRar" - to give you some examples of mainstream-famous compression tools.

I don't know why it's brought up though since it has nothing to do with the topic about use-case(s) of extended private key in WIF format.

In some wallets, at the time of restoration they already scan all possible derivation paths to identify UTXO (e.g. electrum), but just in case I recommend that you save at least the fingerprint and the derivation path, although most wallets use the standard path BIP44, 49, 84, etc.

Electrum doesn't do that.
Its unique Electrum seed phrase has the information to tell the client which derivation path to use. (seed version system)
But it has a feature that can do that on BIP39 mnemonic seed with a click of a button.