[bitcoin-cli] importdescriptors fail if `'` instead `h` as hardened indicator into key origin #28351

Is there an existing issue for this?

• I have searched the existing issues

Current behaviour

I control if the descriptor that I want to import is valid:

$ bitcoin-cli -signet getdescriptorinfo "wsh(or_d(pk([a5c6b76e/48'/1'/0'/2']tpubDF5861hj6vR3iJr3aPjGJz4rNbqDCRujQ21mczzKT5SiedaQqNVgHC8HT9ceyxvMFRoPMx4P6HAcL3NZrUPhRUbwCyj3TKSa64bAfnE3sLh/1/*),and_v(v:pkh([c477fd13/48'/1'/0'/2']tpubDFn7iPbFqGrTQ2aRACNsUK1MXQR4Z6dYfU2nD1WA9ifSaia642j3Wah4n5pBUEpERNWGJsyv3Dv5qwBabC9TLQrwSboKzukw9wmurGu7XVH/1/*),older(3))))"

output:

{
  "descriptor": "wsh(or_d(pk([a5c6b76e/48'/1'/0'/2']tpubDF5861hj6vR3iJr3aPjGJz4rNbqDCRujQ21mczzKT5SiedaQqNVgHC8HT9ceyxvMFRoPMx4P6HAcL3NZrUPhRUbwCyj3TKSa64bAfnE3sLh/1/*),and_v(v:pkh([c477fd13/48'/1'/0'/2']tpubDFn7iPbFqGrTQ2aRACNsUK1MXQR4Z6dYfU2nD1WA9ifSaia642j3Wah4n5pBUEpERNWGJsyv3Dv5qwBabC9TLQrwSboKzukw9wmurGu7XVH/1/*),older(3))))#vpa5k5p6",
  "checksum": "vpa5k5p6",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": false
}

then try to import descriptor (w/ checksum computed by core) returned by getdescriptorinfo:

$ bitcoin-cli -signet -rpcwallet=liana importdescriptors '[{"desc": "wsh(or_d(pk([a5c6b76e/48'/1'/0'/2']tpubDF5861hj6vR3iJr3aPjGJz4rNbqDCRujQ21mczzKT5SiedaQqNVgHC8HT9ceyxvMFRoPMx4P6HAcL3NZrUPhRUbwCyj3TKSa64bAfnE3sLh/1/*),and_v(v:pkh([c477fd13/48'/1'/0'/2']tpubDFn7iPbFqGrTQ2aRACNsUK1MXQR4Z6dYfU2nD1WA9ifSaia642j3Wah4n5pBUEpERNWGJsyv3Dv5qwBabC9TLQrwSboKzukw9wmurGu7XVH/1/*),older(3))))#vpa5k5p6", "range": [0,10000], "timestamp": 1682920310, "active": true, "internal":false}]'

output:

[
  {
    "success": false,
    "error": {
      "code": -5,
      "message": "Provided checksum 'vpa5k5p6' does not match computed checksum 'lkv9vrah'"
    }
  }
]

Expected behaviour

Then I take the checksum given as a reference, and use it to replace the 'wrong' one:

$ bitcoin-cli -signet -rpcwallet=liana importdescriptors '[{"desc": "wsh(or_d(pk([a5c6b76e/48'/1'/0'/2']tpubDF5861hj6vR3iJr3aPjGJz4rNbqDCRujQ21mczzKT5SiedaQqNVgHC8HT9ceyxvMFRoPMx4P6HAcL3NZrUPhRUbwCyj3TKSa64bAfnE3sLh/1/*),and_v(v:pkh([c477fd13/48'/1'/0'/2']tpubDFn7iPbFqGrTQ2aRACNsUK1MXQR4Z6dYfU2nD1WA9ifSaia642j3Wah4n5pBUEpERNWGJsyv3Dv5qwBabC9TLQrwSboKzukw9wmurGu7XVH/1/*),older(3))))#lkv9vrah", "range": [0,10000], "timestamp": 1682920310, "active": true, "internal":false}]'

output:

[
  {
    "success": true
  }
]

seems ok now

Steps to reproduce

Then control the imported descriptor:

$ bitcoin-cli -signet -rpcwallet=liana listdescriptors

output:

{
  "wallet_name": "liana",
  "descriptors": [
    {
      "desc": "wsh(or_d(pk([a5c6b76e/48/1/0/2]tpubDF5861hj6vR3iJr3aPjGJz4rNbqDCRujQ21mczzKT5SiedaQqNVgHC8HT9ceyxvMFRoPMx4P6HAcL3NZrUPhRUbwCyj3TKSa64bAfnE3sLh/1/*),and_v(v:pkh([c477fd13/48/1/0/2]tpubDFn7iPbFqGrTQ2aRACNsUK1MXQR4Z6dYfU2nD1WA9ifSaia642j3Wah4n5pBUEpERNWGJsyv3Dv5qwBabC9TLQrwSboKzukw9wmurGu7XVH/1/*),older(3))))#lkv9vrah",
      "timestamp": 1682920310,
      "active": true,
      "internal": false,
      "range": [
        0,
        10000
      ],
      "next": 0,
      "next_index": 0
    }
  ]
}

if we look at the key origins of the listed descriptor, we can see they do not match (hardened indicator missing) with imported ones:

• [a5c6b76e/48/1/0/2] != [a5c6b76e/48'/1'/0'/2']
• [c477fd13/48/1/0/2] != [c477fd13/48'/1'/0'/2']

Relevant log output

If I use importdescriptors w/ h as hardened indicator, the issue doesn't appear.

How did you obtain Bitcoin Core

Compiled from source

What version of Bitcoin Core are you using?

v25.0

Operating system and version

Arch Linux w/ kernel 6.4.10-arch1-1

Machine specifications

No response

IIRC someone else had an issue like this and the problem was that their shell was eating the '. Can you check that that isn't what's happening?

Can you also try with the latest master branch? There have been a few fixes for descriptors since 25.0 was released, so this may already be fixed.

I just tried with a direct RPC call using this script, everything goes well.

IIRC someone else had an issue like this and the problem was that their shell was eating the '. Can you check that that isn't what's happening?

any idea how to check this? using another shell?

Can you also try with the latest master branch? There have been a few fixes for descriptors since 25.0 was released, so this may already be fixed.

will build from the last master

I just tried with a direct RPC call using this script, everything goes well.

To clarify, the script uses the checksum returned by getdescriptorinfo, and everything imports successfully and listdescriptors shows the correct descriptor as expected?

any idea how to check this? using another shell?

Using a script is good enough. It tells you that there's something wrong with your command or your shell.

---

Looking at this a bit more closely, I see now that the issue is that you've entered the command without escaping your '. You begin the entire imports argument with a ', so the internal ' for the key origins are going to be interpreted by your shell as being the end of a string rather than a character to include in the string. You can even see this in how github renders those characters with different colors. You'll need to figure out how to escape them for your shell (typically \' works), or just use hs.