c0deright commented at 2:06 pm on December 18, 2023: none

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

When starting bitcoind with an old wallet (created July 2019, probably v0.17.x or v0.18.x) the log records 2 errors and one warning that are not self-explanatory.

Might be related to #19051

Expected behaviour

No warning/errors are shown or the errors/warnings are more detailed as to what’s going on.

Steps to reproduce

Run v26.0 with a very old wallet.dat file. I wasn’t able to reproduce this with a wallet.dat file created in v0.12.x, v0.16.3 or v0.18.x. I’m not sure how to reproduce this without uploading the specific wallet.dat file (I’m not able to, sorry).

Relevant log output

Log from v26.0.0

 02023-12-18T13:24:00Z Bitcoin Core version v26.0.0 (release build)
 12023-12-18T13:24:00Z Using the 'x86_shani(1way,2way)' SHA256 implementation
 22023-12-18T13:24:00Z Using RdSeed as an additional entropy source
 32023-12-18T13:24:00Z Using RdRand as an additional entropy source
 4[..]
 52023-12-18T13:24:00Z Using at most 125 automatic connections (1024 file descriptors available)
 62023-12-18T13:24:00Z Using 16 MiB out of 16 MiB requested for signature cache, able to store 524288 elements
 72023-12-18T13:24:00Z Using 16 MiB out of 16 MiB requested for script execution cache, able to store 524288 elements
 82023-12-18T13:24:00Z Script verification uses 7 additional threads
 92023-12-18T13:24:00Z scheduler thread start
10[..]
112023-12-18T13:24:00Z Using wallet directory /home/foobar/.bitcoin
122023-12-18T13:24:00Z init message: Verifying wallet(s)…
132023-12-18T13:24:00Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
142023-12-18T13:24:00Z Using wallet /home/foobar/.bitcoin/wallet.dat
152023-12-18T13:24:00Z BerkeleyEnvironment::Open: LogDir=/home/foobar/.bitcoin/database ErrorFile=/home/foobar/.bitcoin/db.log
16[..]
172023-12-18T13:24:00Z init message: Loading block index…
182023-12-18T13:24:00Z Assuming ancestors of block 00000000000000000001a0a448d6cf2546b06801389cc030b2b18c6491266815 have valid signatures.
192023-12-18T13:24:00Z Setting nMinimumChainWork=000000000000000000000000000000000000000052b2559353df4117b7348b64
202023-12-18T13:24:00Z Opening LevelDB in /home/foobar/.bitcoin/blocks/index
212023-12-18T13:24:00Z Opened LevelDB successfully
222023-12-18T13:24:00Z Using obfuscation key for /home/foobar/.bitcoin/blocks/index: 0000000000000000
232023-12-18T13:24:03Z LoadBlockIndexDB: last block file = 3945
242023-12-18T13:24:03Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=51, size=84327429, heights=817322...817411, time=2023-11-18...2023-11-19)
252023-12-18T13:24:03Z Checking all blk files are present...
262023-12-18T13:24:04Z Initializing chainstate Chainstate [ibd] @ height -1 (null)
272023-12-18T13:24:04Z Opening LevelDB in /home/foobar/.bitcoin/chainstate
282023-12-18T13:24:04Z Opened LevelDB successfully
292023-12-18T13:24:04Z Using obfuscation key for /home/foobar/.bitcoin/chainstate: 9735fc6504867afd
302023-12-18T13:24:04Z Loaded best chain: hashBestChain=0000000000000000000290f359a90a5d57160fd27954703351c6f1bf838941e0 height=816997 date=2023-11-16T10:24:28Z progress=0.983619
312023-12-18T13:24:04Z Opening LevelDB in /home/foobar/.bitcoin/chainstate
322023-12-18T13:24:04Z Opened LevelDB successfully
332023-12-18T13:24:04Z Using obfuscation key for /home/foobar/.bitcoin/chainstate: 9735fc6504867afd
342023-12-18T13:24:04Z [Chainstate [ibd] @ height 816997 (0000000000000000000290f359a90a5d57160fd27954703351c6f1bf838941e0)] resized coinsdb cache to 8.0 MiB
352023-12-18T13:24:04Z [Chainstate [ibd] @ height 816997 (0000000000000000000290f359a90a5d57160fd27954703351c6f1bf838941e0)] resized coinstip cache to 440.0 MiB
362023-12-18T13:24:04Z init message: Verifying blocks…
372023-12-18T13:24:04Z Verifying last 6 blocks at level 3
382023-12-18T13:24:04Z Verification progress: 0%
392023-12-18T13:24:05Z Verification progress: 16%
402023-12-18T13:24:05Z Verification progress: 33%
412023-12-18T13:24:05Z Verification progress: 50%
422023-12-18T13:24:05Z Verification progress: 66%
432023-12-18T13:24:05Z Verification progress: 83%
442023-12-18T13:24:06Z Verification progress: 99%
452023-12-18T13:24:06Z Verification: No coin database inconsistencies in last 6 blocks (26158 transactions)
462023-12-18T13:24:06Z  block index            5148ms
472023-12-18T13:24:06Z init message: Loading wallet…
482023-12-18T13:24:06Z BerkeleyEnvironment::Open: LogDir=/home/foobar/.bitcoin/database ErrorFile=/home/foobar/.bitcoin/db.log
492023-12-18T13:24:06Z [default wallet] Wallet file version = 10500, last client version = 220000
50
512023-12-18T13:24:06Z [default wallet] Error reading wallet database: keymeta found with unexpected path
522023-12-18T13:24:06Z [default wallet] Error reading wallet database: keymeta found with unexpected path
53
542023-12-18T13:24:06Z [default wallet] Legacy Wallet Keys: 657 plaintext, 0 encrypted, 657 w/ metadata, 657 total.
552023-12-18T13:24:06Z [default wallet] Descriptors: 0, Descriptor Keys: 0 plaintext, 0 encrypted, 0 total.
562023-12-18T13:24:06Z [default wallet] Wallet completed loading in               8ms
572023-12-18T13:24:06Z [default wallet] setKeyPool.size() = 600
582023-12-18T13:24:06Z [default wallet] mapWallet.size() = 51
592023-12-18T13:24:06Z [default wallet] m_address_book.size() = 100
60
612023-12-18T13:24:06Z Warning: Error reading /home/foobar/.bitcoin/wallet.dat! All keys read correctly, but transaction data or address metadata may be missing or incorrect.
62
632023-12-18T13:24:06Z Setting NODE_NETWORK on non-prune mode
642023-12-18T13:24:06Z block tree size = 821776
652023-12-18T13:24:06Z nBestHeight = 816997
662023-12-18T13:24:06Z initload thread start
672023-12-18T13:24:06Z torcontrol thread start
682023-12-18T13:24:06Z Imported mempool transactions from disk: 0 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
692023-12-18T13:24:06Z initload thread exit
702023-12-18T13:24:06Z Bound to 127.0.0.1:8334
712023-12-18T13:24:06Z Bound to [::]:8333
722023-12-18T13:24:06Z Bound to 0.0.0.0:8333
732023-12-18T13:24:06Z Loaded 1 addresses from "anchors.dat"
742023-12-18T13:24:06Z 1 block-relay-only anchors will be tried for connections.
752023-12-18T13:24:06Z init message: Starting network threads…
76[..]

Log from v25.1.0

The error/warning is slightly different.

Instead of

Warning: Error reading /home/foobar/.bitcoin/wallet.dat! All keys read correctly, but transaction data or address metadata may be missing or incorrect.

it logs

Warning: Error reading /home/foobar/.bitcoin/wallet.dat! All keys read correctly, but transaction data or address book entries might be missing or incorrect.

How did you obtain Bitcoin Core

Pre-built binaries

What version of Bitcoin Core are you using?

v26.0

Operating system and version

Ubuntu 22.04 LTS

Machine specifications

No response

achow101 commented at 4:48 pm on December 18, 2023: member

The specific thing causing this error would be the lines:

02023-12-18T13:24:06Z [default wallet] Error reading wallet database: keymeta found with unexpected path
12023-12-18T13:24:06Z [default wallet] Error reading wallet database: keymeta found with unexpected path

This means that the stored metadata entries for a 2 keys has derivation paths of an unexpected length (!= 3). This error should be benign, although I think it’s also erroneous since I’m pretty sure it is possible to import keys with derivation path information that would not match the standard pattern the loading code is checking for.

Edit: Actually, such imports would not reach this code. Rather the only way that it is possible to get these errors is if that wallet got corrupted.

c0deright commented at 1:04 pm on December 19, 2023: none

Ok, thank you very much. This is a dedicated test machine and the error did not occur on production machines.

I’ll try dumping the wallet.dat file and importing the keys into a new wallet.

maflcko added the label Wallet on Dec 19, 2023

maflcko added the label Data corruption on Dec 19, 2023

c0deright commented at 2:01 pm on December 19, 2023: none

I did dumpwallet and the file created looks like this:

 0# Wallet dump created by Bitcoin Core v26.0.0
 1# * Created on 2023-12-19T13:47:56Z
 2# * Best block at time of backup was 821931 (00000000000000000003241b21de4d2d4d3505c2941fba3cccec82f1dbdbce4b),
 3#   mined on 2023-12-19T13:46:59Z
 4
 5# extended private masterkey: xprv***********************************************************************************************************
 6
 7L**************************************************n 1970-01-01T00:00:01Z label= # addr=1E*******************************,3H********************************,bc1***************************************
 8K**************************************************E 1970-01-01T00:00:01Z label= # addr=1K*******************************,31********************************,bc1***************************************
 9L**************************************************U 1970-01-01T00:00:01Z label= # addr=1U*******************************,35********************************,bc1***************************************
10L**************************************************3 1970-01-01T00:00:01Z label= # addr=12********************************,3D********************************,bc1***************************************
11L**************************************************7 1970-01-01T00:00:01Z label= # addr=13********************************,3G********************************,bc1***************************************
125*************************************************6 1970-01-01T00:00:01Z label= # addr=13********************************
13K*************************************************Rf 1970-01-01T00:00:01Z label= # addr=13********************************,3P********************************,bc1***************************************
14L*************************************************YD 1970-01-01T00:00:01Z label= # addr=15********************************,38********************************,bc1***************************************
15K*************************************************87 1970-01-01T00:00:01Z label= # addr=16********************************,3M********************************,bc1***************************************
16K*************************************************ib 1970-01-01T00:00:01Z label= # addr=17********************************,3Q********************************,bc1***************************************
17K*************************************************x5 1970-01-01T00:00:01Z label= # addr=17********************************,37********************************,bc1***************************************
18[..]
19L*************************************************1y 2019-12-18T14:06:33Z reserve=1 # addr=3A******************************** hdkeypath=m/0'/0'/66'
20L*************************************************1k 2019-12-18T14:06:33Z reserve=1 # addr=3C******************************** hdkeypath=m/0'/0'/60'
21L*************************************************nz 2019-12-18T14:06:33Z reserve=1 # addr=3J******************************** hdkeypath=m/0'/0'/190'
22K*************************************************Lb 2019-12-18T14:06:33Z inactivehdseed=1 # addr=39********************************
23K*************************************************pJ 2019-12-18T14:06:33Z reserve=1 # addr=3E******************************** hdkeypath=m/0'/0'/54'
24L*************************************************m5 2019-12-18T14:06:33Z label= # addr=3N******************************** hdkeypath=m/0'/0'/5'
25L*************************************************jk 2019-12-18T14:06:33Z reserve=1 # addr=3Q******************************** hdkeypath=m/0'/0'/33'
26K*************************************************Ty 2019-12-18T14:06:33Z reserve=1 # addr=3N******************************** hdkeypath=m/0'/0'/201'
27K*************************************************D1 2019-12-18T14:06:33Z reserve=1 # addr=3K******************************** hdkeypath=m/0'/0'/64'
28K*************************************************o5 2019-12-18T14:06:33Z reserve=1 # addr=3A******************************** hdkeypath=m/0'/0'/108'
29[..]

The 6th key looks odd with it being one character short. One key with has tag inactivehdseed=1.

Might this be the cause of the error messages?

The rest looks good, being change=1, reserve=1 and one being hdseed=1

achow101 commented at 4:51 pm on December 19, 2023: member

Do you see any hdkeypath that doesn’t follow the pattern m/a'/b'/c'?

c0deright commented at 5:58 pm on December 19, 2023: none

Oh, now that you told me where to look … there are indeed two strange looking key paths.

All but two are in the format m/a'/b'/c', e.g. m/0'/1'/289' or m/0'/1'/4'. Most are distinct but eleven key paths are found twice in the dump. And then there are two with a very odd path: m/0'/1'/299'/0'/1'/300' and m/0'/0'/299'/0'/0'/300'.

I’m sure our devs never tested with derivation paths but it is possible that on that particular machine some keys from bitcoin forks were imported, e.g. BTG, BSV or BCH. I will talk to our devs after the holidays to get some feedback as to where these two keys originated so it’s documented here in case someone has the same warnings pop up and ends up here.

Thanks very much, @achow101.

achow101 commented at 8:14 pm on December 19, 2023: member

Most are distinct but eleven key paths are found twice in the dump

Since there is an inactivehdseed, that means that the seed has been rotated, probably by encrypting the wallet. So these duplicated paths are expected. One of the keys is derived from the inactive seed, and the other from the current active seed.

And then there are two with a very odd path: m/0'/1'/299'/0'/1'/300' and m/0'/0'/299'/0'/0'/300'.

This lines up with the errors in the debug.log.

These derivation paths look like the paths for a key got combined with the derivation path for the next key to be derived. I’ve seen this before, but I think only in PR branches, not after being merged. I suspect that these keys were automatically generated and the weird derivation path is the result of a bug in key metadata upgrading code.

Are there any keys with any of the derivation paths m/0'/1'/299', m/0'/1'/300', m/0'/0'/299', or m/0'/0'/300'?

If you are able to, try loading the wallet in 0.17 or earlier and then doing dumpwallet. If you lookup these two addresses (with the weird derivation paths) in the dump, what derivation paths do they have?

It would also be useful to see the actual keymeta records themselves. You can get a dump of raw data stored in the wallet file by using the bitcoin-wallet tool’s dump command (e.g. bitcoin-wallet -dumpfile=dump.txt -wallet=mywallet dump). This will dump all of the records in the database as hex bytes to a text file. Within that file, search for the strings 00000080000000802b01008000000080000000802c010080 and 00000080010000802b01008000000080010000802c010080. These are the derivation paths as they would be stored in the wallet file. Then you can copy the lines with those strings and paste them here. Those lines will be the entire metadata records for these two keys. These are safe to share as they will only contain the public key, a version number, the time the key was created, the seed’s id (hash of the seed), and the derivation path.

c0deright commented at 8:31 pm on December 19, 2023: none

Since there is an inactivehdseed, that means that the seed has been rotated, probably by encrypting the wallet. So these duplicated paths are expected. One of the keys is derived from the inactive seed, and the other from the current active seed.

Not encrypted but a dumpwallet dump from a different wallet.dat (might be from a fork) was imported withimportwallet into the already existing wallet.dat which most likely made the old hdseed inactive and the imported one active (or vice versa).

Are there any keys with any of the derivation paths m/0'/1'/299', m/0'/1'/300', m/0'/0'/299', or m/0'/0'/300'?

Only these two:

0reserve=1 [..] hdkeypath=m/0'/0'/299'
1reserve=1 [..] hdkeypath=m/0'/0'/300'

If you are able to, try loading the wallet in 0.17 or earlier and then doing dumpwallet. If you lookup these two addresses (with the weird derivation paths) in the dump, what derivation paths do they have?

I did as you described and dumpwallet with 0.17.0 gives

hdkeypath=m/0'/1'/300' for the address with hdkeypath=m/0'/1'/299'/0'/1'/300' in v26.0
hdkeypath=m/0'/0'/300' for the address with hdkeypath=m/0'/0'/299'/0'/0'/300' in v26.0

Both addresses/keys were created on 2021-10-28 according to the dumpwallet file and are of type change=1

c0deright commented at 8:46 pm on December 19, 2023: none

bitcoin-wallet doesn’t create any file:

0% bitcoin-wallet -datadir=. -dumpfile=026.dump -wallet=wallet.dat dump
1Error reading wallet.dat! All keys read correctly, but transaction data or address book entries might be missing or incorrect.

achow101 commented at 9:23 pm on December 19, 2023: member

bitcoin-wallet doesn’t create any file:

Oh, that’s a bug, Should be simple to fix. In any case, I don’t think that dump will be needed since the dumpwallet output should be enough to have an idea of what was stored.

The dumpwallet file has a xprv at the top. Can you try deriving the 4 keys at the derivation paths I mentioned above and see which match the lines with the weird derivation paths? I’m pretty sure the wallet just stored the wrong derivation paths somehow.

Both addresses/keys were created on 2021-10-28

Any idea what version was running on that date?

c0deright commented at 10:00 pm on December 19, 2023: none

Will try tomorrow using https://github.com/dan-da/hd-wallet-derive

c0deright commented at 11:58 am on December 20, 2023: none

derived keys

I used https://github.com/dan-da/hd-wallet-derive to derive

301 keys in path m/0'/0'/0' to m/0'/0'/300'
301 keys in path m/0'/1'/0' to m/0'/1'/300'

from the xprv like so:

0php hd-wallet-derive.php -g --cols=path,privkey --key=xprv... --path="m/0'/0'/x'" --numderive 301 > xprv-0.txt
1php hd-wallet-derive.php -g --cols=path,privkey --key=xprv... --path="m/0'/1'/x'" --numderive 301 > xprv-1.txt

Then I took all the private keys from the walletdump output and grepped for the keys in the 2 .txt files and only found 11 matches for the following paths:

m/0'/0'/0' to m/0'/0'/5' in xprv-0.txt
m/0'/1'/0' to m/0'/1'/4' in xprv-1.txt

There are 623 keys in the walletdump output with a hdkeypath info but only 11 can be derived from the xprv? That’s odd to me.

Edit

Both addresses/keys were created on 2021-10-28

Any idea what version was running on that date?

Timeline according to company communication history

2021-10-28T09:48Z

We upgraded from v0.19.1 to v22.0 on that dedicated test server.

2021-10-28T11:42Z

getwalletinfo

 0{
 1  "walletname": "",
 2  "walletversion": 169900,
 3  "format": "bdb",
 4  "balance": 0.00032451,
 5  "unconfirmed_balance": 0.00000000,
 6  "immature_balance": 0.00000000,
 7  "txcount": 50,
 8  "keypoololdest": 1576677994,
 9  "keypoolsize": 300,
10  "hdseedid": "8136................................49b9",
11  "keypoolsize_hd_internal": 300,
12  "paytxfee": 0.00000000,
13  "private_keys_enabled": true,
14  "avoid_reuse": false,
15  "scanning": false,
16  "descriptors": false
17}

2021-10-28T13:33Z

One key is generated/imported:

0L**************************************************G 2021-10-28T13:33:14Z reserve=1 # addr=3********************************x hdkeypath=m/0'/0'/2'

2021-10-28T14:05Z

15 keys are generated/imported, among them two with the bogus keypath:

 0K**************************************************G 2021-10-28T14:05:29Z change=1 # addr=32*******************************T hdkeypath=m/0'/0'/302'
 1K**************************************************7 2021-10-28T14:05:29Z change=1 # addr=3E*******************************7 hdkeypath=m/0'/1'/305'
 2L**************************************************K 2021-10-28T14:05:29Z change=1 # addr=3A*******************************n hdkeypath=m/0'/0'/305'
 3L**************************************************i 2021-10-28T14:05:29Z reserve=1 # addr=32*******************************x hdkeypath=m/0'/1'/3'
 4K**************************************************c 2021-10-28T14:05:29Z change=1 # addr=3D******************************MN hdkeypath=m/0'/0'/301'
 5L**************************************************3 2021-10-28T14:05:29Z change=1 # addr=3F******************************n7 hdkeypath=m/0'/1'/302'
 6L**************************************************C 2021-10-28T14:05:29Z change=1 # addr=3Q******************************5F hdkeypath=m/0'/1'/304'
 7K**************************************************i 2021-10-28T14:05:29Z reserve=1 # addr=38******************************Sg hdkeypath=m/0'/0'/3'
 8K**************************************************N 2021-10-28T14:05:29Z change=1 # addr=3M******************************HV hdkeypath=m/0'/1'/303'
 9K**************************************************3 2021-10-28T14:05:29Z change=1 # addr=3D******************************8C hdkeypath=m/0'/0'/304'
10K**************************************************t 2021-10-28T14:05:29Z change=1 # addr=38******************************8w hdkeypath=m/0'/1'/299'/0'/1'/300'
11K**************************************************t 2021-10-28T14:05:29Z change=1 # addr=3A******************************xU hdkeypath=m/0'/1'/301'
12K**************************************************x 2021-10-28T14:05:29Z change=1 # addr=3D******************************fD hdkeypath=m/0'/0'/299'/0'/0'/300'
13L**************************************************T 2021-10-28T14:05:29Z reserve=1 # addr=3M******************************du hdkeypath=m/0'/0'/4'
14L**************************************************z 2021-10-28T14:05:29Z change=1 # addr=3F******************************yC hdkeypath=m/0'/0'/303'

bitcoin-wallet

I compiled v26.0 with patch from #29117 and used bitcoin-wallet to dump the wallet.dat into bitcoin-wallet.dump

0% grep 00000080000000802b01008000000080000000802c010080 bitcoin-wallet.dump | xxd -r -p | hd
100000000  07 6b 65 79 6d 65 74 61  21 03 5c 24 01 45 a6 43  |.keymeta!.\$.E.C|
200000010  29 a2 d6 f9 75 38 69 b2  a2 a3 ff 08 bb df 37 7d  |)...u8i.......7}|
300000020  50 4d 36 82 83 c3 fb e9  bd 0b 0c 00 00 00 29 ae  |PM6...........).|
400000030  7a 61 00 00 00 00 0c 6d  2f 30 27 2f 30 27 2f 33  |za.....m/0'/0'/3|
500000040  30 30 27 1a f5 3c d5 83  ec fc ff 41 e8 2b a8 8e  |00'..<.....A.+..|
600000050  4e 85 6e 04 46 b9 58 1b  e3 33 09 06 00 00 00 80  |N.n.F.X..3......|
700000060  00 00 00 80 2b 01 00 80  00 00 00 80 00 00 00 80  |....+...........|
800000070  2c 01 00 80 01                                    |,....|
900000075

0% grep 00000080010000802b01008000000080010000802c010080 bitcoin-wallet.dump | xxd -r -p | hd
100000000  07 6b 65 79 6d 65 74 61  21 02 21 03 73 d4 c0 a2  |.keymeta!.!.s...|
200000010  2a d0 49 f1 22 85 9a 90  36 8c 86 e5 35 8e 43 bc  |*.I."...6...5.C.|
300000020  ea 84 08 60 4c 8c a5 f8  98 50 0c 00 00 00 29 ae  |...`L....P....).|
400000030  7a 61 00 00 00 00 0c 6d  2f 30 27 2f 31 27 2f 33  |za.....m/0'/1'/3|
500000040  30 30 27 1a f5 3c d5 83  ec fc ff 41 e8 2b a8 8e  |00'..<.....A.+..|
600000050  4e 85 6e 04 46 b9 58 1b  e3 33 09 06 00 00 00 80  |N.n.F.X..3......|
700000060  01 00 00 80 2b 01 00 80  00 00 00 80 01 00 00 80  |....+...........|
800000070  2c 01 00 80 01                                    |,....|
900000075

c0deright commented at 2:57 pm on December 20, 2023: none

Let me know if I can help with debugging this any further.

bitcoin deleted a comment on Dec 20, 2023

achow101 commented at 5:39 pm on December 20, 2023: member

I was able to replicate the bug. I believe this is only an issue with 0.21.x and 22.x as the bug was fixed by #23304 which was first released in 23.0.

The issue occurs when inactive key chains are topped up. There was an off-by-one where loading would erroneously find the last index derived rather than the next index to be derived (last index + 1), and so it would end up re-deriving that last index, which I think is what causes the weird derivation path. Specifically, DeriveNewChildKey takes a metadata object and overwrites the hdKeypath string but appends to key_origin.path, so if it gets the same object twice, then it would overwrite hdKeypath with the path it just derived, but append that path to key_origin.path. This results in the derivation path that looks like it’s two derivation paths concatenated, because that’s what it is.

The exact mechanism is not entirely clear to me though since DeriveNewChildKey is always called by GenerateNewKey which always provides it with a new metadata object. However, empirically, I can replicate the issue on 22.x, but the same procedure does not have the issue on 23.x.

It should be possible for the wallet to detect when this error had occurred previously and be able to fix it automatically. I’ll see if I can put together a fix.

There are 623 keys in the walletdump output with a hdkeypath info but only 11 can be derived from the xprv? That’s odd to me.

This is expected as the hd seed has been rotated (most commonly by encrypting the wallet). The one shown at the top will be for the current seed, while the wallet will still store and have metadata for all of the keys generated with the previous seed. We can further see that the keys with the odd derivation paths are generated from a seed whose id does not match the active one, which is consistent with the way that I replicated the issue.

c0deright commented at 8:38 pm on December 20, 2023: none

Thanks for your thorough explanation of this bug!

achow101 commented at 8:48 pm on December 20, 2023: member

#29124 should automatically fix the bad metadata. Can you try running that?

c0deright commented at 9:50 pm on December 20, 2023: none

Looks good:

02023-12-20T21:34:16Z init message: Loading wallet…
12023-12-20T21:34:16Z BerkeleyEnvironment::Open: LogDir=/home/foobar/.bitcoin/database ErrorFile=/home/foobar/.bitcoin/db.log
22023-12-20T21:34:16Z [default wallet] Wallet file version = 10500, last client version = 220000
32023-12-20T21:34:16Z [default wallet] Repairing derivation path for 0221......850[default wallet] Repairing derivation path for 035c.....d0b[default wallet] Legacy Wallet Keys: 657 plaintext, 0 encrypted, 657 w/ metadata, 657 total.

No warning/error regarding keymeta. The WalletLogPrintf call should end with \n, though.

Did a diff between v26.0.0 RPC dumpwallet and your version.

0 [..]
1-[..] hdkeypath=m/0'/1'/299'/0'/1'/300'
2+[..] hdkeypath=m/0'/1'/300'
3 [..]
4-[..] hdkeypath=m/0'/0'/299'/0'/0'/300'
5+[..] hdkeypath=m/0'/0'/300'
6 [..]

Looks fixed for me.

c0deright closed this on Dec 20, 2023

fanquake referenced this in commit 04978c2e18 on Jan 5, 2024

bitcoin locked this on Dec 19, 2024

achow101 commented at 8:02 pm on April 21, 2025: member

Apparently migrating the legacy wallet to descriptors is also a way to fix this issue.

Old wallet.dat: Error reading wallet database: keymeta found with unexpected path / All keys read correctly, but transaction data or address metadata may be missing or incorrect #29109