getdescriptorinfo returns unusable descriptor #29320

Is there an existing issue for this?

• I have searched the existing issues

Current behaviour

NOTE: Replace bch.sh below in the code with bitcoin-cli -signet.

Let's have a random new testnet descriptor wallet with following private descriptors:

~/.bitcoin/signet$ bch.sh listdescriptors true | jq .descriptors[].desc | tail -1
"wpkh(tprv8ZgxMBicQKsPdpPsVvhB5XZtRfRWGqH1uwJNmG27dQgDwTS76oCd3hKbn3zERUZjG2fCgdKe8rqT2NomNbCgGSUQ829rJkTLUWvGKzyHX7Z/84h/1h/0h/1/*)#duvgfk6y"

I will use just the one on the last line.

When the prvate descriptor above is used with getdescriptorinfo RPC call I get following:

~/.bitcoin/signet$ bch.sh getdescriptorinfo "wpkh(tprv8ZgxMBicQKsPdpPsVvhB5XZtRfRWGqH1uwJNmG27dQgDwTS76oCd3hKbn3zERUZjG2fCgdKe8rqT2NomNbCgGSUQ829rJkTLUWvGKzyHX7Z/84h/1h/0h/1/*)#duvgfk6y"
{
  "descriptor": "wpkh(tpubD6NzVbkrYhZ4XHRfPaMmUwDzzgwSSATvVEuA3n4R3gUcmwgsjC2DEBwTxB4qBjSBoofF3xKGAsQE3GhBDSFi6b8PcDwXLdEoNxrovTFmyYt/84h/1h/0h/1/*)#9zp9fyaf",
  "checksum": "duvgfk6y",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": true
}

When the just-returned descriptor is used in deriveaddress it ends with an error:

~/.bitcoin/signet$ bch.sh deriveaddresses "wpkh(tpubD6NzVbkrYhZ4XHRfPaMmUwDzzgwSSATvVEuA3n4R3gUcmwgsjC2DEBwTxB4qBjSBoofF3xKGAsQE3GhBDSFi6b8PcDwXLdEoNxrovTFmyYt/84h/1h/0h/1/*)#9zp9fyaf"  '[0,1]'
error code: -5
error message:
Cannot derive script without private keys

If the wallet is queried by listdescriptors, just public, I get this for the same derivation path:

~/.bitcoin/signet$ bch.sh listdescriptors | jq .descriptors[].desc | tail -1
"wpkh([823c2027/84h/1h/0h]tpubDDPGZQssk8ekvcN85aXhvz5omhZdQPWcczP21RqCHw7i5ce89zgYHoxowE8HrUUi2XUr4Vv4x48Ykhw7JBCH6G8QUfgRRR9UPgbC74DdNC4/1/*)#spvfr65h"

When I use the above just-returned public descriptor it derives addresses well:

~/.bitcoin/signet$ bch.sh deriveaddresses "wpkh([823c2027/84h/1h/0h]tpubDDPGZQssk8ekvcN85aXhvz5omhZdQPWcczP21RqCHw7i5ce89zgYHoxowE8HrUUi2XUr4Vv4x48Ykhw7JBCH6G8QUfgRRR9UPgbC74DdNC4/1/*)#spvfr65h" '[0,1]'
[
  "tb1qegtflj2zzv6wqwh0zgh7zeztv2ek6awsvz4fpk",
  "tb1qslc5s8gd5zd7fa3cj64zt7kmlnw348x6q6cg28"
]

Expected behaviour

I would expect also the getdescriptorinfo for the private descriptor to return a valid public descriptor usable for deriving addresses.

Steps to reproduce

myderive() {
  bitcoin-cli -signet getdescriptorinfo "$1" | jq -r .descriptor | while read a; do bitcoin-cli -signet deriveaddresses "$a" '[0,1]'; done
}

myderive "wpkh(tprv8ZgxMBicQKsPdpPsVvhB5XZtRfRWGqH1uwJNmG27dQgDwTS76oCd3hKbn3zERUZjG2fCgdKe8rqT2NomNbCgGSUQ829rJkTLUWvGKzyHX7Z/84h/1h/0h/1/*)#duvgfk6y"
# above fails

myderive "wpkh([823c2027/84h/1h/0h]tpubDDPGZQssk8ekvcN85aXhvz5omhZdQPWcczP21RqCHw7i5ce89zgYHoxowE8HrUUi2XUr4Vv4x48Ykhw7JBCH6G8QUfgRRR9UPgbC74DdNC4/1/*)#spvfr65h"

Former errs, the latter works. Both are returned from listdescriptors, but former is the private from listdescriptors true.

Relevant log output

No response

How did you obtain Bitcoin Core

Pre-built binaries

What version of Bitcoin Core are you using?

v26.0.0

Operating system and version

Pop!_OS 22.04 LTS (like Ubuntu, just uses zram)

Machine specifications

x86_64 SSD big enough for Signet (proper, non-custom)

Great catch! To summarize, the RPC is returning an extended PUBLIC key followed by a hardened derivation path. Which is not usable.

The purpose of the descriptor result of getdescriptorinfo is to reflect a descriptor that basically matches the user's input, just without including any private keys. listdescriptors specifically returns normalized descriptors so that they can be imported elsewhere.

getdescriptorinfo could also return the normalized descriptor, but it intentionally does not do that for descriptor. I suppose a separate field containing the normalized form could be added.

I can confirm this issue has been resolved in the current Bitcoin Core v28.0.0.

Test Results with current Bitcoin Core:

• Private descriptor: wpkh(tprv8ZgxMBicQKsPex2iyDeZBBVUEXgmM2AaQMCXS3Ea6n4Jq7GBH7WXKD6svcVkheMiUHRN55CDmHD5VBamQdeHYfdyy7H4Bpox98dB4y5EdiZ/84h/1h/0h/1/*)#y3f8rvu5

• getdescriptorinfo now returns: wpkh([6ec4a9d6/84h/1h/0h]tpubDC2eVxnwvoKRpatNU2E3kB8W1v12AcVvtE4M525uiPF1dWuQhLnjNSVJEX5CeAk8gfm6fV9Rmu6LvVzGP2fPr1X9JfDPGz4hToKFbcGBD32/1/*)#0k803cul

• deriveaddresses works successfully: ["tb1qzvlelxwr0na3applkpjtndnkkja8z9yk8g07uu", "tb1qj0wxxgfga3d4eq738cj9jkjcw3wckhc7u60lfs"]

The fix ensures that getdescriptorinfo returns normalized descriptors with origin information (fingerprint and path), making them compatible with deriveaddresses just like descriptors returned by listdescriptors.

Please test with the latest Bitcoin Core version to confirm the fix.

Yes. It works also on v29.0.0 (Termux arm64 build). Thanks!

Closing.