listdescriptors true fails with 'Can't get descriptor string' in non-watch-only descriptor wallet

mrtnetwork commented at 6:40 pm on March 15, 2025: none

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

When running the command:

0bitcoin-cli listdescriptors true

it fails with the error:

0error code: -4
1error message:
2Can't get descriptor string.

even though the wallet is not watch-only and is a descriptor wallet.

However, when running:

0bitcoin-cli listdescriptors false

the command works fine and returns descriptor information, but without private keys.

Expected behaviour

Since the wallet is not watch-only and is a descriptor wallet, the command should succeed, just like listdescriptors false, but with the private key information included.

Steps to reproduce

Verify that the wallet is a descriptor wallet:

0{
1  "walletname": "BTC",
2  "walletversion": 169900,
3  "format": "sqlite",
4  "keypoolsize_hd_internal": 4000,
5  "private_keys_enabled": true,
6  "descriptors": true,
7  "external_signer": false,
8  "blank": false,
9}

Relevant log output

I didn’t find any related errors in the debug file, but I listed my descriptor for reference

 0{
 1  "descriptors": [
 2    {
 3      "desc": "pkh([761f1ef4/44h/1h/0h]tpubDDeGeaPE1STPq4dQFhc5grg8pn6pqyttBtX6Pkw8cAVKesnJr7wYFF7LKy2ysifbPSKDyBT3hHjAg9rftJdPVKLUrGgan7pmML9CFeDuua6/0/*)#cnspa9u5"
 4    },
 5    {
 6      "desc": "pkh([761f1ef4/44h/1h/0h]tpubDDeGeaPE1STPq4dQFhc5grg8pn6pqyttBtX6Pkw8cAVKesnJr7wYFF7LKy2ysifbPSKDyBT3hHjAg9rftJdPVKLUrGgan7pmML9CFeDuua6/1/*)#f84qqsvv"
 7    },
 8    {
 9      "desc": "pkh([761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/100)#t96q85nr"
10    },
11    {
12      "desc": "sh(wpkh([761f1ef4/49h/1h/0h]tpubDDohgQvP57jvmvVzmKFo1JjZjwWRAaYyL7aPG4ZPiiNjnbSDKBHxgPSBmBx9Esjf4HxxeEeRVdkiGRaJmVRofHBMLtQzHxKmRbAg9oMxEmw/0/*))#h40wmz6r"
13    },
14    {
15      "desc": "sh(wpkh([761f1ef4/49h/1h/0h]tpubDDohgQvP57jvmvVzmKFo1JjZjwWRAaYyL7aPG4ZPiiNjnbSDKBHxgPSBmBx9Esjf4HxxeEeRVdkiGRaJmVRofHBMLtQzHxKmRbAg9oMxEmw/1/*))#z5pcra0u"
16    },
17    {
18      "desc": "sh(wsh(multi(2,[761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/2,[761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/3)))#3455mcsd"
19    },
20    {
21      "desc": "tr([761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/*)#rrrwmyl6"
22    },
23    {
24      "desc": "tr([761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/1,multi_a(2,[761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/2,[761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/3))#teu9thwc"
25    },
26    {
27      "desc": "tr([761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/1,{pk([761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/2),pk([761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/1)})#597an7jq"
28    },
29    {
30      "desc": "tr([761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/1/*)#jhx0x30z"
31    },
32    {
33      "desc": "tr(ca46e9fad132afe73c7efcc02039225d2f4626cf476f6ca91ab56ad2d1956029,multi_a(2,[761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/2,[761f1ef4/86h/1h/0h]tpubDDRksBabSitMWcvdvWwVzhEvwFC9Bf77ASZRGHtoMhYr6AFDChuQtNxEvWqtjNy5Vqmd7DKwh5b41NM1oT3YfNRWBMrbcw53da4NwmJ12Td/0/3))#guq2rvkj"
34    },
35    {
36      "desc": "wpkh([761f1ef4/84h/1h/0h]tpubDCSU3vbXvSzLszkaX4dBv5bsovXH5JqoR6rpCToEJZJ8kiZb3VZkWpoKnf5Sr5aGjxCqbDhfR6Z8JtT5rT3CLj7aC8NfLUjEtxhZB9PNHxs/0/*)#lf9s05rn"
37    },
38    {
39      "desc": "wpkh([761f1ef4/84h/1h/0h]tpubDCSU3vbXvSzLszkaX4dBv5bsovXH5JqoR6rpCToEJZJ8kiZb3VZkWpoKnf5Sr5aGjxCqbDhfR6Z8JtT5rT3CLj7aC8NfLUjEtxhZB9PNHxs/1/*)#waq3jpnt"
40    }
41  ]
42}

How did you obtain Bitcoin Core

Pre-built binaries

What version of Bitcoin Core are you using?

Bitcoin Core RPC client version v28.1.0

Operating system and version

Windows 11 Home 26100.3476

Machine specifications

No response

furszy commented at 1:58 pm on March 17, 2025: member

This occurs when the wallet does not contain all key/script paths key material (e.g. taproot descriptor with an internal pubkey). Test exercising the behavior and explaining the issue further: https://github.com/furszy/bitcoin-core/commit/970efeb0fb2632d714e0f444b4ac89278eb80b28.

willcl-ark added the label Wallet on Mar 19, 2025

willcl-ark added the label RPC/REST/ZMQ on Mar 19, 2025

rkrux commented at 12:47 pm on April 3, 2025: contributor

Were the descriptors mentioned in the description collected using listdescriptors false?

I’m asking because all these descriptors seem to be using public keys, at least all the taproot ones because I get the following error when I try to import them in my wallet.

0[
1  {
2    "success": false,
3    "error": {
4      "code": -4,
5      "message": "Cannot import descriptor without private keys to a wallet with private keys enabled"
6    }
7  }
8]

This PR #32186 attempts to fix the issue where the private keys are not present for all the taproot spending paths as mentioned in the comment #32078 (comment). For example: the descriptor may have the private key for the keypath spend and none for the script path spend, or the descriptor could have at least one private key for any of the scripts in the scriptpath spend but not have the private key for the keypath spend. @mrtnetwork By chance, do you remember having any such^ descriptor in your wallet?

mrtnetwork commented at 4:36 am on April 4, 2025: none

This PR #32186 attempts to fix the issue where the private keys are not present for all the taproot spending paths as mentioned in the comment #32078 (comment). For example: the descriptor may have the private key for the keypath spend and none for the script path spend, or the descriptor could have at least one private key for any of the scripts in the scriptpath spend but not have the private key for the keypath spend.

@mrtnetwork By chance, do you remember having any such^ descriptor in your wallet?

For Taproot, I have 3–4 addresses that use x-only pubkeys with no script path. However, one of them is a 2-of-2 Taproot multisig. All private keys are available in the wallet. I’m working only on the testnet network. If you need more details, I can upload the wallet backup for you.

Randy808 commented at 1:35 pm on April 6, 2025: contributor

listdescriptors will also fail for any sh or wsh descriptors.:

0bitcoin-cli importdescriptors '[{"desc": "wsh(thresh(2,pk(tprv8ZgxMBicQKsPdzuc344mDaeUk5zseMcRK9Hst8xodskNu3YbQG5NxLa2X17PUU5yXQhptiBE7F5W5cgEmsfQg4Y21Y18w4DJhLxSb8CurDf),s:pk(tpubD6NzVbkrYhZ4YiCvExLvH4yh1k3jFGf5irm6TsrArY8GYdEhYVdztQTBtTirmRc6XfSJpH9tayUdnngaJZKDaa2zbqEY29DfcGZW8iRVGUY),sln:older(2)))#jgkkfj86", "timestamp": "now"}]'
1
2bitcoin-cli listdescriptors true

ToStringHelper will fail the serialization if any of the keys in the expression are missing a private key. @rkrux’s PR handles the taproot case, but I think a general solution is needed. If there’s even one private key available, it needs to be visible in listdescriptors true so users can make complete backups.

rkrux commented at 2:49 pm on April 7, 2025: contributor

Interesting, tried these^ keys in a wsh descriptor that causes the listdescriptors to throw as well.

 0➜  bitcoin git:(master) ✗ bitcoinclireg importdescriptors '[{"desc": "wsh(multi(2,tprv8ZgxMBicQKsPdzuc344mDaeUk5zseMcRK9Hst8xodskNu3YbQG5NxLa2X17PUU5yXQhptiBE7F5W5cgEmsfQg4Y21Y18w4DJhLxSb8CurDf,tpubD6NzVbkrYhZ4YiCvExLvH4yh1k3jFGf5irm6TsrArY8GYdEhYVdztQTBtTirmRc6XfSJpH9tayUdnngaJZKDaa2zbqEY29DfcGZW8iRVGUY))#a0tl2jdn", "timestamp": "now"}]'
 1[
 2  {
 3    "success": true,
 4    "warnings": [
 5      "Not all private keys provided. Some wallet functionality may return unexpected errors"
 6    ]
 7  }
 8]
 9➜  bitcoin git:(master) ✗ bitcoinclireg listdescriptors true                      
10error code: -4
11error message:
12Can't get descriptor string.

I’m digging into this for a solution.

rkrux commented at 2:54 pm on April 7, 2025: contributor

If there’s even one private key available, it needs to be visible in listdescriptors true so users can make complete backups.

Even though listdescriptors true should work correctly ideally, I don’t suppose only this RPC throwing an error would lead to the user being unable to make complete backups?

Randy808 commented at 3:41 pm on April 7, 2025: contributor

If I export that descriptor from another wallet, import it into Bitcoin Core, delete my old wallet, and later try to export that descriptor with the same information, I won’t be able to. As a user listdescriptors true is the way I would be expecting to backup all the descriptors in my wallet. Without this, there is no other mechanism besides me tinkering with the code. Having this one “problem” descriptor prevent the other descriptors in my wallet from being displayed is also something I think should be changed.

I didn’t want to derail your PR, this was just something I’ve noticed for a while and was going to make my own issue/fix for. I think the PR to address the problem for taproot descriptors is a step in the right direction but I wanted to mention the broader issue that needs to be solved.

sipa commented at 3:52 pm on April 7, 2025: member

ToStringHelper will fail the serialization if any of the keys in the expression are missing a private key. @rkrux’s PR handles the taproot case, but I think a general solution is needed. If there’s even one private key available, it needs to be visible in listdescriptors true so users can make complete backups.

I agree. See my comment on #32186.

rkrux commented at 5:04 pm on April 7, 2025: contributor

Thank you for sharing more details.

I’ve put my PR #32186 in draft while I work on a more generic solution.

listdescriptors true fails with ‘Can’t get descriptor string’ in non-watch-only descriptor wallet #32078