Trick to find PrivatKey Bitcoin Core descriptor wallet, is this method safe?

[PytagoraZ]

I'm still new to Bitcoin Core, but yesterday we came across what I thought was an interesting discussion on our local forum about wallet descriptors in Bitcoin Core. By default as far as I know we can't retrieve the private key, as @achow101 said

Descriptor wallets do not allow dumpprivkey because the fundamental principle behind descriptor wallets is that private keys are not enough information to transport a wallet. Private keys lack derivation information and lack information about what kind of scripts to create. They also do not work for wallets that have anything more complicated than just single key scripts. Thus allowing a RPC that only outputs private keys would be working against the point of having descriptors.

Instead of dumpprivkey, descriptor wallets have listdescriptors. This will output all of the descriptors stored in the wallet, which means that it will include information about derivation paths and scripts to create. Descriptors are a full backup of the key and script information stored in the wallet. With 23.0, listdescriptors will also be able to optionally output descriptors containing private keys.

However one of the members on our local forum was able to provide a way to find the private key in the wallet descriptor, via third party support of course. I haven't tried it but one of the other members on the local forum has tried it and had success

Here's How:

- Open "console" and enter passphrase walletpassphrase "your password" 600, If your wallet has encrypt passphrase
- Next use the argument getaddressinfo "your address"
   ~ Note the type of script address in the parent descriptor section ("parent_desc") pkh, wpkh, sh or tr
   ~ Note the hdkeypath
- Next use the argument listdescriptors true
- From the results, look for a descriptor ("desc") that has the same script address type (pkh, wpkh, sh or tr) as the "parent_desc" that you previously noted And make sure it has the same hdkeypath too
- Note the extended private key (xprv key)
- Download BIP39 Tool (Mnemonic Code Converter) https://github.com/iancoleman/bip39/releases , and run it offline (turn off the internet network)
- Enter the xprv key in the BIP32 Root Key column in the BIP39 Tool
- Done, you will find the private key from the address on the descriptor wallet

A link to the discussion on our local board, can be found HERE. Is the method above safe to do?

[Husna QA]

A link to the discussion on our local board, can be found HERE. Is the method above safe to do?

As far as I know, if the procedure for using a third-party tool, in this case, the BIP39 tool (https://github.com/iancoleman/bip39/), is correct, then the private key can be used.

It's just that if I refer to the following achow101 explanation:

Descriptor wallets do not allow dumpprivkey because the fundamental principle behind descriptor wallets is that private keys are not enough information to transport a wallet. Private keys lack derivation information and lack information about what kind of scripts to create. They also do not work for wallets that have anything more complicated than just single key scripts. Thus allowing a RPC that only outputs private keys would be working against the point of having descriptors.

Instead of dumpprivkey, descriptor wallets have listdescriptors. This will output all of the descriptors stored in the wallet, which means that it will include information about derivation paths and scripts to create. Descriptors are a full backup of the key and script information stored in the wallet. With 23.0, listdescriptors will also be able to optionally output descriptors containing private keys.

The next problem is the private key obtained through the BIP39 tool, which, in my opinion, will eliminate the function of the wallet descriptor, for example, when it is reused in the recovery process via the importprivkey command.

[PytagoraZ]

The next problem is the private key obtained through the BIP39 tool, which, in my opinion, will eliminate the function of the wallet descriptor, for example, when it is reused in the recovery process via the importprivkey command.

Yep, I read the article from achow101's blog: What's Coming To The Bitcoin Core Wallet in 0.21, What I understand from the article is that the wallet descriptor uses a script system while the previous bitcoin core wallet used privatkey, I don't know which is the best between the two and what is the reason for the bitcoin core developer to remove privatkey in the wallet descriptor. Also, wallet descriptor is the default option in bitcoin core for now, so I think bitcoin core developers suggest to create wallets in the form of wallet descriptor

I hope @achow101 is willing to explain in more detail regarding this issue and use a third party to see the private key of wallet descriptor is safe or not.

[nc50lc]

A link to the discussion on our local board, can be found HERE. Is the method above safe to do?

It looks similar to my instructions here: http://bitcointalk.org/index.php?topic=5449245.msg62109703#msg62109703

The method is safe as long as it's done in an Air-Gap machine.
However, the exported private key must be kept safe at all cost because it could compromise all of the other child keys of -
its parent extended private key (xprv) if the extended public key from the wallet is compromised with it.

Unlike the legacy wallet.dat with pure hardened derivation path, the new descriptor wallet derives the receiving/change derivation paths and its child keys without "hardened" derivation.
It means that a child private key and its public parent can be used to compute its private parent key, then the rest of the descriptor's private keys with that xprv.

So, only do that if exporting the private key is really necessary.