Exported wallet content meaning; Balance on reserved taddr


It is second time I noticed my z_gettotalbalance shows more than the sum of all balances of addresses printed by
zcash-cli getaddressesbyaccount “”
zcash-cli z_listaddresses

I’ve dig a bit dipper and I found out that when I do z_exportWallet to a file, then the file contains a lot more of an addresses than shown by above mentioned commands. Some are marked label=, some change=1 and some reserve=1.
I found the difference in my balances, I was looking for, on one of reserve=1 addresses by running this one liner:

cat <exported_wallet_file_txt> | awk ‘{print $5}’ | sed ‘s/addr=//g’ | while read txAddress ; do if [[ $txAddress =~ ^t.*$ ]]; then echo -n "$txAddress " ; zcash-cli z_getbalance $txAddress ; fi; done

When I checked the address in blockchain explorer it turned out it received cash during some transfers done from my label= taddr.

So here come my questions:

  1. where can I read more about the meaning of reseve, change and label in exported wallet file?
  2. why some cash ends up on my random addresses after transaction ?
  3. … why on reserve address not label ?

Thanks in advance for answers
Best regards

z_gettotalbalance should return both the shielded and transparent balance as reported by getbalance.

All of the transparent address stuff in Bitcoin-related and the equivalent command that would export the private keys of Bitcoin addresses is dumpwallet - this will return the same details just without the z-addrs included at the bottom. You’ll be able to find a lot more detail about specifics if you google for the Bitcoin dumpwallet command.

Initially, the wallet generates 100 transparent addresses by default (the keypool) - you can see this with getinfo and look for keypoolsize, these are basically pre-generated t-addrs to use. When you create a new address to use or change from a transaction is sent, one of these addresses is used. So in that output the addresses you have used are either label or change whereas the reserve addresses are the unused addresses in the keypool.

As for your question about random addresses after transactions. With Bitcoin you need to spend an entire UTXO so if it is 1 BTC and you send 0.1 BTC to buy something then the 0.9 BTC will be sent as change. In Bitcoin-style that Zcash inherits this will be sent by default to a new address out of your keypool and marked as change. Just for info this isn’t actually the case with z-addrs where change is returned to the sending address (as privacy concerns are a non-factor for address reuse).

Hopefully, that’s vaugeully clear but there will be a load of better info just googling the relevant terms for Bitcoin.

Hi @garethtdavies !

I will read further about bitcoin dumpwallet, but already I can see one thing in my case is not exactly as you kindly explained.
My case is only about taddrs. It is that the change ends up in the taddr that is not marked change, but reserve. And it is really not the one time story. As I can see the mentioned taddr received actually 3 changes from three of my transactions, but it is still reserve.

  1. Isn’t this something strange ? Should it be marked change as you wrote ?
  2. Moreover is there a command to list change taddrs, except from looking into the exported wallet ?
    zcash-cli getaddressesbyaccount “” does only show taddrs marked label.
  3. And finally, would I mess up my wallet if I manually change the marks by the addresses (e.g. reserve->label) in exported wallet and then import it back ?

Thanks and regards !

1 - I don’t know, sorry, it seems strange to me!
2 - Try listaddressgroupings which will also return the change addresses.
3 - I wouldn’t - at least without knowing you have a proper backup. What do you hope to achieve by doing this - are you actually having an issue or is this just for curiosity?

2 - great, thanks ! listaddressgrouping does the trick, I can see there the taddr with change (one marked reserve).
3 - pure curiosity, no issue yet. As I prefer to use core wallet, I would like to understand how it works to avoid stupid mistakes :wink: