dumpprivkey doesn't work in descriptor wallet

Crypto2 commented at 2:03 am on September 8, 2022: none

In a descriptor wallet it returns “This type of wallet does not support this command” instead of the private key. Even though the wallet doesn’t store the key directly it obviously knows how to build it since it can spend the funds so it should do that and return it. There are just too many cases where a private key needs to be dumped and it shouldn’t be a nightmare of RPC calls and 3rd party scripts to try to get it, that just doesn’t make sense usability-wise.

Just a common case point for us for example, we still use p2sh-segwit for our users since too many places still don’t support bech32 and pretty regularly people still send LTC to our BTC addresses (smh, I know) and we need to easily be able to dump the key to recover it for them.

Crypto2 added the label Bug on Sep 8, 2022

maflcko added the label Feature on Sep 8, 2022

maflcko added the label Wallet on Sep 8, 2022

maflcko removed the label Bug on Sep 8, 2022

Crypto2 commented at 8:07 am on September 8, 2022: none

I’ve read a bit there may be some worry about people leaking their xpub and an address’s key since it’s using non-hardened derivation. I would argue that making dumpprivkey function would actually be a much safer scenario than making less technical or just unlucky people “figure it out” with their xpriv and descriptors since:

Option 1) dumprivkey - maximum leaked data is the private key of one address

Option 2) listdescriptors + derivation - copy/pasting xprv into unknown 3rd party software which may be malicious (compromising entire wallet), them asking people for “help” and getting scammed, etc.

There are also things like clipboard monitoring viruses, which again the potential damage there is the private key of one address versus the xprv of the entire wallet.

Overall I think it’s actually much safer to make dumpprivkey work normally.

achow101 commented at 4:54 pm on September 8, 2022: member

Option 1) dumprivkey - maximum leaked data is the private key of one address

No, it is not. The maximum leaked data is the xprv of the parent. It sounds like you misunderstand the concern with the parent xpub and child private key - given a parent xpub and a child private key derived with unhardened derivation, the parent xprv can be computed. It is far less obvious that this is the case, and therefore far more dangerous than retrieving the xprv. The xprv is more obviously something that is meant to be kept secret.

Crypto2 commented at 5:31 pm on September 8, 2022: none

It sounds like you misunderstood? dumpprivkey doesn’t return the xpub as well; that would have to be leaked separately.

Given only the address + address privkey there is no danger. This could also require a special config entry to enable if you want to be extra secure; really just for dumpprivkey in general not even specific to these address types. In crypto it’s not even really acceptable have a user running their own wallet and want the private key to their own address and be like “Nah, we don’t trust you with that” lol.

achow101 commented at 5:44 pm on September 8, 2022: member

The point is that users will have to both know that they can’t share the xpub with anyone they may have shared a child private key with, or vice versa, and remember this at a future time when they may wish to share such information with others. Furthermore, just with your example of clipboard malware, the malware that steals the child private key can also now get the entire xprv as xpubs are not encrypted - it can get the private key from the clipboard, and the xpub by reading the wallet database from disk. And since users are unlikely to know about this possibility, we should make it harder for users to shoot themselves in the foot.

In crypto it’s not even really acceptable have a user running their own wallet and want the private key to their own address and be like “Nah, we don’t trust you with that” lol.

We give them the xprv. That’s way more information than just a single private key. We already don’t trust users with a lot of things. We try to avoid giving people the ability to footgun themselves. Frankly, the biggest threat to a user’s Bitcoin is the user themselves.

Crypto2 commented at 6:19 pm on September 8, 2022: none

Exactly, that’s why dumpprivkey is the better solution since it minimizes those risks. Yes, give them warnings and/or force them to add a config option; but at the end of the day it’s safer than having people who don’t know what they are doing playing around with their xprv’s with much less warning than that about the dangers of it.

bitcoin deleted a comment on Sep 8, 2022

sipa commented at 8:30 pm on September 12, 2022: member

I really don’t think we should support dumpprivkey for descriptor wallets; that’s:

a huge footgun; you can’t tell from a dumped key whether it’ll leak your entire wallet or not, as it depends on whether it was hardened or non-hardened. This concern didn’t exist with legacy wallets as they were always hardened, but descriptor wallets are by default non-hardened. If your keys are derived in a non-hardened way, all keys should be considered to really be representations of the same secret material, and exporting one is the same as exporting all. And when exporting the private descriptor (which includes the xprv), it’s obvious you are exporting everything.
It’s just the wrong direction to move in, as descriptor wallets aren’t key-centric anymore (multisig descriptors are first class wallets, and can’t support this cleanly).

What do you think about alternatively providing an RPC or a tool that can derive and return the private keys involved in a descriptor?

w0xlt commented at 0:05 am on September 13, 2022: contributor

I proposed the #25366 to address this issue, but there are risks that are also mentioned here.

EDIT: I wasn’t remembering, but I removed the private key(s) from the RPC return as requested by the reviewers, but you can check the PR description and the discussion for the original results (which included the private keys).

Crypto2 commented at 4:23 pm on September 13, 2022: none

There are just too many cases where you need a private key to correct an error or otherwise as I mentioned above - and it’s just wrong in general to tell users “sorry you can’t have your private key because we say so, so go dump your xprv and do some potentially even more risky stuff to figure it out”. I fully support a requirement of an extra parameter or config entry to enable the RPC to work, so the user has to specifically acknowledge the risk that way before it works for them.

bitcoin deleted a comment on Oct 10, 2022

achow101 commented at 5:24 pm on October 27, 2022: member

Closing as there is a lack of support for this feature.

achow101 closed this on Oct 27, 2022

Crypto2 commented at 6:34 pm on October 27, 2022: none

There is a ton of support for it, just not from the Bitcoin devs :(

bitcoin locked this on Oct 27, 2023

dumpprivkey doesn’t work in descriptor wallet #26046