Where do I find complete documentation on what the console command "dumpwallet" output means?
Sample of my testnet output:

# Wallet dump created by Bitcoin v0.21.0   
# * Created on 2021-01-21T16:59:50Z   
# * Best block at time of backup was 1905234 (00000000e26170d0f846a334a1bfdfebe8da906c5),   
#   mined on 2021-01-21T17:05:05Z    

# extended private masterkey: tpR2efnJMh85ufpQcYSTwrrKrYJ   

cTdH4SbvTR 1970-01-01T00:00:01Z label= # addr=mnb8RSpTqvhLh8Q6,2MudYFE2awqc,tbvhpur8zf35ql3yx5h9nu   
cRaKzuR9MCVwAxVa3aAZrVh15YbV 2019-08-26T01:19:00Z reserve=1 # addr=tb1q3qc52q hdkeypath=m/0'/0'/222'   
cT2ozo5xcj6iCe4dTfywan3qJnib 2019-08-26T01:19:00Z hdseed=1 # addr=tb1qzqtu25qsue0a5pp3hg8lkftclf8ds   
cNb2K9tUhQaeXiVz2Jt2Wq9DMLdf 2019-08-26T01:19:00Z reserve=1 # addr=tb14d7lx hdkeypath=m/0'/0'/117'   

.....4040 lines   
# End of dump  

What's "hdkeypath"?
What's "reserve" ?
What's "hdseed"?
Why does "addr" sometimes have 1 address and sometimes 3 addresses?
Why does my dump have 4040 lines?
(for purposes of formatting & discretion, all addrs/keys are mangled)

This is the best I could find. It offers no detail about the output:


AFAIK there isn't any documentation of dumpwallet's output. You need to read the source code to know. I suppose I can just document it here though.

The dumpwallet output contains comments. Comments are prefixed by a #. This can be found at the beginning of a line or in the middle. Anything on that line following the # is a comment and will not be parsed by importwallet. Comments are used to provide additional information to the user reading the dumpwallet output but prevent the importwallet parser from doing anything with the data in the comment.

The first 4 lines are just some extra information to the user to know which version created the dump and at what time. It includes the current clock time as well as the time and hash of the current best block.

For HD wallets, this is followed by the extended master private key.

After that, each line lists out an individual private key and some metadata about that private key. The private key will be encoded using the Wallet Import Format.

The private key will then be followed by a timestamp. This timestamp is in UTC time and is the time that the private key was created and added to the wallet.

Each private key will have one of the following metadata fields: label, hdseed, reserve, inactivehdseed, or `change.

  • label: This is a label assigned to one of the addresses for this private key. Since a single private key can have multiple addresses, and each of those addresses a different label, this just gets one of this labels. It's a holdover from when one private key corresponded to one address. All receiving addresses will have a label even if it does not have a label. For those addresses, the label is the empty string so you may see label= a lot.
  • hdseed: This private keys is the current active HD seed. You will always see this field as hdseed=1. The HD seed is a BIP 32 seed. Bitcoin Core stores this as a private key and it is therefore indistinguishable from other private keys. This HD seed is used to produce the extended master private key found earlier. It may also be used to derive many of the other private keys in this wallet. There should only be one key with hdseed=1.
  • reserve: This indicates that the private key is part of the keypool. You will always see this as reserve=1. The key has not been requested for use as a receiving address nor as a change address, it is in reserve in the keypool.
  • inactivehdseed: This private key was a HD seed previously used by the wallet but is no longer the currently active HD seed. You will always see this as inactivehdseed=1. It is the same meaning as the key with hdseed=1 except it is not currently active.
  • change: This key is no longer in the keypool and it's address is not a receiving address. The assumption is that such addresses are change addresses. So this key is marked as being change by having this metadata field. You will always see it as change=1.

Following the metadata, on the same line, will be a comment with some additional metadata that may be useful to the user but will not be parsed by importwallet. This will have 2 fields: addr and hdkeypath.

  • addr: This is a comma separate list of addresses that have been used for this private key. Since a single private key can have multiple addresses, you may see multiple addresses in this field.
  • hdkeypath: This is a string representing the BIP 32 derivation path for this private key. In cases where there is only one key marked as hdseed=1, you can derive this private key by using the extended master private key at the top of the file and then deriving from it the key with this derivation path. When there are multiple HD seeds in a wallet (i.e. when there are inactivehdseed=1 keys), it is not possible to know which seed this key was derived from without trying to derive from them all.

After each of the private keys is listed, you will see lines for scripts stored in the wallet. This is similar to how private keys are listed.

Each script is written out in hexadecimal. The script is then followed by a timestamp indicating the time that the script was added to the wallet. It will then be followed by script=1 to indicate that this line is for a script. Lastly there will be a comment containing an addr field. This address will be the P2SH address for this script.

At the end of the file is a comment End of dump to indicate the end of the wallet dump.

When you use dumpwallet, you should expect to see several thousand lines. This is because Bitcoin Core, by default, has a keypool of 1000 receiving keys and 1000 change keys. For a newly created wallet, there will be 2000 key lines.

If you have not imported any scripts, you should have the same number of key lines as script lines. This is because each key has a segwit script. This is an artifact of how the Bitcoin Core wallet supports segwit.

If you have imported any scripts such as multisig scripts or addresses which are not yours, then you will see those scripts in the script lines as well.

  • Andrew, under what circumstances will there be reserve=1 keys? Do they have a practical use today? – Donn Lee Mar 4 at 16:36
  • @DonnLee There will always be reserve=1 keys (except for descriptor wallets, but that's an entirely different thing). They are useful today and are still important. – Andrew Chow Mar 4 at 18:09
  • reserve addresses: bitcoin.stackexchange.com/questions/96982/… – Donn Lee Mar 4 at 23:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.