Topic: Why is there no possibility to export privkeys when creating a descriptor wallet (Read 490 times)

Currently in Bitcoin Core you cannot export private keys out of a descriptor wallet yet, though this might have changed since the last time I read about this (which was some time last year).

That being said, you can indeed generate private keys from a descriptor wallet if it is the kind that represents a private key or master private key/seed. There are Python scripts and libraries out there on Github which can help with that. Check Bitcoin Core's tests folder for example.

What is there to teach about it?

The design of descriptor wallets and migration is such that, when actually using the wallet, you don't notice anything different. It is not any different to send or receive Bitcoin than it is with a legacy wallet. The wallet software has abstracted everything away for you, just as it was for legacy wallets.

... Then learn how to do that? How did you know how to export and import a private key? You had to read it somewhere, just like you can read somewhere (e.g. my earlier posts) about how to that. Are you looking for specific instruction and can't find it?

It's been a few years and the question still remains the same, I'm afraid of migrating to a descriptor wallet because of this, there is no tutorial on the internet teaching how to use it.

The core only allows you to send coins while it is 100% sync, what should I do when my balance is in a descriptor wallet and I don't know how to export and import the private descriptor from that wallet to another wallet in case of emergency?

Do you understand that this is the question of a common user?

I can't accomplish any of this, as the dev guide is not clear for a common user who has no understanding of programming.

That's unsafe. With unhardened derivation, if you have a child private key and the parent xpub, the parent xprv can be derived. Bitcoin Core now uses the various derivation path standards all of which use unhardened derivation. So allowing individual child keys to be exported exposes the user to potential wallet compromise. One of the requirements for moving to unhardened derivation was to disallow child private key export.

Exporting a child private key and the parent descriptor at the same time would be the same as exporting the parent descriptor with its xprv, except it is entirely non-obvious to the user that these two things are equivalent.

I don't think it's at all acceptable to continue with the obviously confusing solution if there is a solution which does not have the confusion in the first place. Continuing with the old just because adding something new will be confusing the users during the transition is not the way to move forward at all. We've been adding more and more output types, the confusion is just going to get worse without descriptors.

Furthermore, people have been looking at using more and more complicated scripts, and adding even more complicated things like covenants. These are fundamentally incompatible with having just private keys. Imagine the confusion when every wallet decides to define their own standards for dealing with these. Descriptors provides a framework for which all of these things can be implemented with and done in a standardized fashion. For at least these new things, everyone will be compatible as they will largely be using the descriptors standard that now exists.

I don't think that's it. Then why remove dumpprivkey entirely? Why not update that CLI response to include the WIF and a descriptor of the path? Remember how long `getinfo` was deprecated before it was actually functionally removed? Not sure what the rush is...



The confusion we all see on a regular basis is because of the backwards compatibility of output types, and because wallets are free to deviate from a standard (as they should be able to) -- to that end I think we just need to accept that confusion will always exist.

Creating yet another new standard that may not be adopted by most wallets just creates an opportunity in the future for more confusion. Similar to how we saw wallets completely diverge on an HD standard.

I know the goal is to improve bitcoin, help others and make loss of funds more difficult but I think in a few years time we will have some users with descriptors and some without. Users asking how to recover funds without descriptors, or how to import if their wallet doesn't support descriptors.

AFAICT OP just wants to be able to import things from one wallet to another. This doesn't require generating anything outside of Bitcoin Core.

I've opened a PR to update that: https://github.com/bitcoin/bitcoin/pull/24977

Active means it is actively being used to generate new addresses. Internal means it is being used to generate change addresses.

I just tried listdescriptors and i can see why OP having hard time. Descriptor documentation[1] is quite nice with lots of example, but you need to generate private key from xpub (either by writing script using Bitcoin library or specific tool). Also, what does key active and interval exactly mean? Explanation from help listdescriptors isn't exactly helpful.


[1] https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md

Yes, you can take additional steps to convert the WIF key into an address and use that to confirm that it is indeed the correct key. However, from observing other threads and guides that discuss using dumpprivkey to show that the wallet has the private key, most do not go beyond just using dumpprivkey and getting a string output. The point was that if you're trusting the wallet to output a private key that purports to be for a particular address (and aren't doing any further verification of that), then you can just as well trust it when it says it has the private key for an address.

And real users have demonstrated confusion and difficulty with using just private keys and moving them to different wallets. The only input I'm seeing here is "this is new and I don't know how to use it".

I have seen people complaining about not being able to see their address(es) because they imported their key(s) into a wallet that only makes a specific type of address. I have seen people confused why when they import a xpub or xprv that the wallet generates a completely different set of addresses than they are expecting. Descriptor solve these problems by explicitly stating what kind of addresses to create and what the derivation paths are.

You can't possibly be telling me that it is easier for a user to know which of the 4 different types of (standard) addresses that can be produced from a single private key, and know how to specify that to the wallet they are trying to import to. Hell, most users probably don't know what address types even are, nor how to distinguish between them. Descriptors are easier because users don't have to think about that at all.

I agree with OP I'm not a fan of the new wallet design.


What do you mean? Any WIF key can easily be converted to an address by many different libraries in many languages that could easily confirm Bitcoin Core is not "outputting gibberish". 


No, a real user is telling you it's actually more difficult. You'd likely benefit by taking their input into consideration. A bunch of core devs probably isn't the best test group for usability. Just because someone knows more about something than someone else, doesn't mean they know best.

It's sad that Core continues to miss on UX year after year... 

Just type listdescriptors into the debug console that you are already using. You can use listdescriptors true with 23.0 to also get the private keys included in those descriptors.

No, it actually makes things easier. Less stuff to remember and less footguns. It's just hard right now because it's new and people aren't used to it yet.

Other wallets are starting to support descriptors now too. You can import those descriptors into Sparrow wallet for example. https://outputdescriptors.org/ has a list of some wallets that support descriptors.

Furthermore, descriptors are relatively human readable. They're entirely plain text. You can extract the xpubs/xprvs from them and import those directly into other wallets that support importing BIP 32 keys. They contain the derivation paths to use as well so you will know what derivation path to specify when you import. They also specify the script (address) type to create and that will help with importing.

Being able to supposedly export private keys does not guarantee that you actually have them. For all you know, Bitcoin Core could be outputting gibberish when you use dumpprivkey. If all you want is to see private keys, then listdescriptors will do that.

You have some options:
1. You can use non-descriptor wallets. Then you can create addresses and import them to descriptor wallets, in this way you can backup and move keys in the old way.
2. You can backup wallet.dat from descriptor wallets. Then, you can import that to Core and use, or you can use a tool that will restore keys from that file.
3. You can use dumpwallet command and get all keys from text file.
4. The problem exists only because things are not-yet-implemented. But they will be implemented in new versions of Core (and you could import your wallet.dat to them).
In general, Taproot is active, but the clients are not yet ready to fully support it. So, it will take some time to implement things, for now you can use some older address type, or try to use Taproot manually. For example, creating Taproot address is still not possible through getnewaddress. If you use Taproot on mainnet now, then it means that you know how to use console properly, or you have a wallet that can handle it correctly.

Edit: By the way, it is possible that we will have getnewdescriptor or something like that, instead of getnewaddress. In general, handling things through descriptors is so different, that I expect there will be separate commands for that.

I took a quick look, when I have time, I'll analyze it more carefully, but I found the whole process quite difficult at first, remembering that I wanted to learn the descriptors to use in the Bitcoin Core console when I need it.

I think going that route makes things a lot more difficult, especially for non-technical users.

And the main thing, I hope someone knows how to answer my initial question and concern, what am I going to do to use the keys from my wallet on the Core in another wallet when the Core crashes?

As now with a descriptor wallet, I won't have access to the private keys, how do I know that I own my BTC's? This point I wanted to get to...

https://bitcoindevkit.org/descriptors/

Is there any guide on descriptors with practical examples to learn how to use this feature?

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.

When creating a wallet with wallet descriptor enabled on Bitcoin Core, one of the most useful features, which is to import/export keys from addresses, is no longer possible, stating that this type of wallet does not support this command.



In the image above it shows me trying to export private keys from 2 types of addresses, legacy and taproot.

So in the next version of Core v23.0 which will probably support taproot addresses, for me to use taproot will I need to create another type of wallet (with wallet descriptor enabled in the create option)?

Do taproot addresses (bech32m) not have derivation paths like legacy, p2sh-segwit and bech32 addresses that are generated through (bip44, bip49 and bip84)?

If this is really true, then if I have problems with the Core I will no longer be able to export private keys to other software such as electrum and be totally dependent on the core.