Incomplete information in wallet backup and/or unexpected BIP32 seed #15884

I have a testnet wallet I've used for some time in Coldcard testing, specifically to generate PSBT files for signing exercises. However, this wallet isn't generating PSBT files I want anymore. Specifically, it is making (unsigned, funded) PSBT files referencing a BIP32 fingerprint that I don't expect.

At first I thought it was an issue with encoding the values in the PSBT, and so I dumped the wallet backup to understand the problem.

After some investigation, I find that the wallet backup doesn't contain enough information about the true contents of the wallet. There appears to be two private masterkeys in effect, and I have no way to get the details of the unknown one, aside from its fingerprint.

Using the tprv at the top of the file, I can reconstruct the private key of only 2049 of the 5506 addresses listed in the file.

Specifically, here are two lines that are in conflict (IMHO), because both have the same derivation path, m/0'/0'/100', and yet different private keys!

cU7tcXeY4FtTAx5nH8uGaVSjTLVKfw8KxPmQeRs6nzucuSK33YQJ 2019-04-12T13:39:26Z reserve=1 # addr=2N9UWoUEdn8s2TcBid2wV2KMCp1Fk38r1h8 hdkeypath=m/0'/0'/100'
cRtqv76chtn8KNrgeanMiUFaKHu9hK1E724Rj7fkZ6Rb5cGHR6q2 2018-05-17T14:25:41Z change=1 # addr=2N9aAP4Saa8njbBUkT54fnGpd5q8sGHv5xs hdkeypath=m/0'/0'/100'

The first one makes sense based on the tprv at the top of the file. The other does not, and must be based on a different seed.

(There is only one hdseed=1 line in the wallet backup.)

Doing getaddressinfo on the two addresses, indicates a different hdmasterfingerprint which corresponds to the unhelpful fingerprint I was seeing in the PSBT files:

getaddressinfo 2N9UWoUEdn8s2TcBid2wV2KMCp1Fk38r1h8
{
  "address": "2N9UWoUEdn8s2TcBid2wV2KMCp1Fk38r1h8",
  "scriptPubKey": "a914b205748e497252c0b8c9aef4ad0c58e240d6980c87",
  "ismine": true,
  "solvable": true,
  "desc": "sh(wpkh([645716a2/0'/0'/100']0350b7abfc54438575aa9cb3ef9e9e3684df49887acbfbbc7f2c1f76b81f96c619))#gypp23kt",
  "iswatchonly": false,
  "isscript": true,
  "iswitness": false,
  "script": "witness_v0_keyhash",
  "hex": "0014baebc7c67a0313b882d4635cf069736138cc4bba",
  "pubkey": "0350b7abfc54438575aa9cb3ef9e9e3684df49887acbfbbc7f2c1f76b81f96c619",
  "embedded": {
    "isscript": false,
    "iswitness": true,
    "witness_version": 0,
    "witness_program": "baebc7c67a0313b882d4635cf069736138cc4bba",
    "pubkey": "0350b7abfc54438575aa9cb3ef9e9e3684df49887acbfbbc7f2c1f76b81f96c619",
    "address": "tb1qht4u03n6qvfm3qk5vdw0q6tnvyuvcja6q4027j",
    "scriptPubKey": "0014baebc7c67a0313b882d4635cf069736138cc4bba"
  },
  "ischange": true,
  "timestamp": 1555076366,
  "hdkeypath": "m/0'/0'/100'",
  "hdseedid": "3551b50538470b990d080f23226c37d98312e81e",
  "hdmasterfingerprint": "645716a2",
  "labels": [
  ]
}

getaddressinfo 2N9aAP4Saa8njbBUkT54fnGpd5q8sGHv5xs
{
  "address": "2N9aAP4Saa8njbBUkT54fnGpd5q8sGHv5xs",
  "scriptPubKey": "a914b316e792f59c35560228a5d1d5dc2eca09f98e9c87",
  "ismine": true,
  "solvable": true,
  "desc": "sh(wpkh([d79ed905/0'/0'/100']0222fe08b7bf79fb0e0f82f50e22c1da4d2db33776983c5a883d70d97524694df1))#a8p3w0dm",
  "iswatchonly": false,
  "isscript": true,
  "iswitness": false,
  "script": "witness_v0_keyhash",
  "hex": "001434471490de4b879e516af87cc9c5569f67335f8b",
  "pubkey": "0222fe08b7bf79fb0e0f82f50e22c1da4d2db33776983c5a883d70d97524694df1",
  "embedded": {
    "isscript": false,
    "iswitness": true,
    "witness_version": 0,
    "witness_program": "34471490de4b879e516af87cc9c5569f67335f8b",
    "pubkey": "0222fe08b7bf79fb0e0f82f50e22c1da4d2db33776983c5a883d70d97524694df1",
    "address": "tb1qx3r3fyx7fwreu5t2lp7vn32knannxhuteu8h8f",
    "scriptPubKey": "001434471490de4b879e516af87cc9c5569f67335f8b"
  },
  "ischange": true,
  "timestamp": 1526567141,
  "hdkeypath": "m/0'/0'/100'",
  "hdseedid": "e0301044cb99ba73398c9187c32bad4a9cdf9247",
  "hdmasterfingerprint": "d79ed905",
  "labels": [
  ]
}

645716a2 is the fingerprint expected, and I have no idea where d79ed905 comes from!

My questions/comments:

• What RPC call do I make to dump the private key with hdseed "d79ed905" ??
• This wallet has been around a while, since 16.0, and might have accumulated some cruft. This analysis was done with 18.0

Generally, WTF is going on here, and is it safe that the wallet backup hasn't captured all the HD seeds?! If it has captured that value, where can I find the secrets for d79ed905 in the wallet backup?

How did you get the private keys from the Core wallet onto the Coldcard or vice versa? Is the wallet encrypted? Do you see any keys marked as inactivehdseed=1 or have hdkeypath=s that aren't the seed you found?

• since dumpmasterprivkey was removed, I've been parsing the wallet backup to get the key from the comment at the top of the backup file.
• inactivehdseed does not appear in the backup file
• there is exactly one line with hdkeypath=s (also has hdseed=1) .. I haven't decoded it, but I'm assuming it maps to the tprv at the top of the file.
• not encrypted

Did you import any private keys or public keys using importmulti? Were these imported with key origin information (i.e. imported a descriptor)?

Can you check the PSBT that was created and look at the scriptPubKey being spent? Is it the scriptPubKey that you expect?

• Pretty sure I've never used that command (importmulti). My test code has always worked by syncing the Coldcard simulator to the (testnet) key of Core.
• When I use walletcreatefundedpsbt the inputs are sometimes a mix of values from the unknown seed and the seed I expected. The BIP32 derivation and redeem script are consistent with the values given by getaddressinfo in both cases.

Do any of the keys not have an hdkeypath specified? Can you try computing the key ids for all of the keys and see if any match the seed id that's unknown? You can do this by calculating the public key for each private key, hashing it with hash160, and then byteswap the hash and compare it to the seed id given by getaddressinfo.

Thanks for those ideas, @achow101 ... I didn't manage to do what you asked, but I did see this:

• there is one line with "hdseed=1" and "hdkeypath=s" and it's the BIP32 seed I expect
• but there is another line with "change=1" and "hdkeypath=m"
• that line is for address 2NBPEVQDLcwo9EDEPDAy65tZfSLLQhco4Uv

getaddressinfo 2NBPEVQDLcwo9EDEPDAy65tZfSLLQhco4Uv
{
  "address": "2NBPEVQDLcwo9EDEPDAy65tZfSLLQhco4Uv",
  "scriptPubKey": "a914c6f602c8240e536b5b0e86e01cc8f414b2d676b687",
  "ismine": true,
  "solvable": true,
  "desc": "sh(wpkh([d79ed905]025d387fa771a6127fcb0fdbc82de3d705ee6dd01e7b02eef8c397bfb02e031d46))#2pecer0k",
  "iswatchonly": false,
  "isscript": true,
  "iswitness": false,
  "script": "witness_v0_keyhash",
  "hex": "00144792df9c4aad2bc387918c3973ba99cb441030e0",
  "pubkey": "025d387fa771a6127fcb0fdbc82de3d705ee6dd01e7b02eef8c397bfb02e031d46",
  "embedded": {
    "isscript": false,
    "iswitness": true,
    "witness_version": 0,
    "witness_program": "4792df9c4aad2bc387918c3973ba99cb441030e0",
    "pubkey": "025d387fa771a6127fcb0fdbc82de3d705ee6dd01e7b02eef8c397bfb02e031d46",
    "address": "tb1qg7fdl8z2454u8pu33suh8w5eedzpqv8qk6z2lm",
    "scriptPubKey": "00144792df9c4aad2bc387918c3973ba99cb441030e0"
  },
  "ischange": true,
  "timestamp": 1526567141,
  "hdkeypath": "m",
  "hdseedid": "e0301044cb99ba73398c9187c32bad4a9cdf9247",
  "hdmasterfingerprint": "d79ed905",
  "labels": [
  ]
}

• so this is "m" (master seed) for the unexpected BIP32 seed "d79ed905"
• but it's a change address?
• I'm going to decode that line now to see if it contains the BIP32 seed I need

• yes, that line in the backup file does contain the seed for the unexpected BIP32 key in the wallet

Did you use sethdseed at any point? Are you sure you are creating the wallet dump in 0.18? It looks like it should be one produced by 0.17. 0.18 shouldn't be providing the hdkeypath for the seed.

It looks like what happened here is that this wallet is originally from 0.16 or earlier but, when used in 0.17, a new hd seed was generated and that hd seed became the one being used. You can tell because 0.16 and earlier called the seed hdmaster and assigned it the keypath of m. This was changed in 0.17 to call it hdseed and give it a keypath of s. Since you found the key with a keypath of m, that means that that was the seed that was generated by 0.16 or earlier. It is a bug that the keypath (and metadata) for the seed is not updated to 0.17's definitions.

but it's a change address?

It isn't. Change is the default value if it can't be determined as to what kind of key it is. In this case, hdkeypath of m is not recognized as an inactive seed as it should be.

• I do not remember using "sethdseed" at any point, but I agree that's what it looks like happened.
• I did dump the wallet initially on 0.17 when I started investigating. With 0.18, it dumps the "hdseed=1" line without a hdkeypath.

Now that I understand the problem better, I don't think it's worth investigating. It's just multi-version bitrot and not something regular users will see.