Hey everyone,
I’ve been messing around with two HD wallets using the latest version of Bitcoin Core. I ran some RPC commands in the bitcoin-qt app while keeping it synced, and both wallets are encrypted with sqlite format. I made sure to upgrade to the latest Bitcoin Core software.
1. First thing I noticed
When I use the getwalletinfo command, it doesn't show any hdseedid value at all, and the key seems to be missing too.
But when I check an address with getaddressinfo, it gives me the hdseedid as all zeros. The hdkeypath and hdmasterfingerprint are there, though.
Can anyone shed some light on this?
2. Second thing
These two wallets are at different stages. One’s older and has more transactions, yet it’s actually smaller in size. The older wallet is almost half the size of the newer one.
Appreciate any insights!
Your wallets are Descriptor Wallets. These fields have no meaning for Descriptor Wallets and so are either omitted or have a meaningless value.
The size of the wallet depends on its usage. One wallet could have larger transactions, or more addresses used, or more descriptors, etc.
Hello achow101,
thank you for answering.
Regarding the second question something seems off.
One wallet has a lot of transactions and different addresses.
The newer wallet has few transactions and no additionals created addresses.
So my natural question is. How is it possible for the newer wallet with some few transactions to weight so much in bytes?
Is there any method to output in a plain text the content of the db?, even with encrypted private keys, to just see what's different inside them?
Is there any moethod to verify wallet integrity?
Thanks
The wallet tool has a dump command to export all of the records as hex to a text file. Use bitcoin-wallet -dumpfile=<path to output file location> -wallet=<wallet name> dump
Loading a wallet verifies integrity every time.
Whenever you create a wallet (which is now generated by default in descriptor format), each descriptor generates up to 1000 keys by default. You can set the number using the command line option keypoolrefill. This acts as a gap limit, that is, when this "limit" is reached, the wallet generates another 1000 keys, and so on.
So even if you have a more recent wallet.dat file and haven't clicked to generate new addresses, these addresses, not yet displayed in the GUI, are actually stored in your wallet.dat keystore.
All new keys generated will be derived from your extended private key from your descriptor, so there's no need to worry about making a new backup.
This is why both keystores are the "same size", the addresses are already "pre-generated" in your keystore and they will be displayed in the GUI as you click to "generate a new receiving address".
See more details at: https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/keypoolrefill/
Hello achow101, thank you for your answer. I didn't have time to check the source code on github, but when you says that the wallet is verified at each load, does bitcoin core verify the priv keys corrisponding to the pub keys? even if encrypted? For example checking a saved priv key checksum in the wallet?
Thank you Forsyth Jones for answering. The question was a bit different. Having 2 wallets, one older with more transactions and another newer with few transactions, how is it possible that the newer size in bytes is double?
Yep, normal for newer Core wallets. Since recent versions use descriptor wallets, hdseedid isnt shown in getwalletinfo, and legacy fields return zeros because seeds are handled differently
The presence of hdkeypath and hdmasterfingerprint simply reflects the descriptor structure.
As for file size, wallet.dat grows based on metadata, transactions, and internal structure changes, so an older wallet can still end up smaller depending on how it was created or upgraded.