Topic: question about bitcoin-qt and change addresses (Read 2273 times)

In the "Console" of the "Debug Window" under the "Help" menu, you can enter:


You should get a list of every unspent output in the wallet including among other things:

• The value of the output
• The address associated with the output
• The transaction hash of the transaction where the output was created

Is there a way to see the hidden change addresses?

I want to put my balance into a read-only blockchain.info wallet and cannot get all of the BTC value into the wallet.  I do not want to have to browse all of my transactions using blockchain.info and figure which address(es) were the destination and which address was the change.

With default settings, Bitcoin-Qt wallet pre-generates a queue of addresses that it stores in wallet.dat and doesn't tell you about.  Any time you request a new address (or any time the wallet needs a new address for "change" when sending a transaction), it draws from this queue and then generates a new address to add to the queue so that the total number of addresses in the queue is 100.  As long as you backup regularly (I'd suggest every time the sum of new receive addresses and sent transactions reaches 25 or so) and keep multiple recent bcakups (I'd suggest the 3 most recent). You should be ok.  If the hard drive failure occurs upon send, the address that is being used for the "change" should exist in the queue of all three copies of wallet.dat.  When you recover the backup, Bitcoin-Qt will see that the address has bitcoins associated with it and will remove it from the queue of unused addresses and use it as an active address in your wallet.

If you frequently generate a lot of transactions or a lot of receive addresses, you might consider increasing the size of the queue.

Change addresses are just part of the regular chain of addresses in your wallet.  If you have 100 addresses in your keypool and generate 100 new receiving addresses, the following address (in Bitcoin-Qt) will no longer be valid.  If you are sending lots of transactions, each one that requires sending change will eat up another address in your key pool.

This is one reason to use a client with a deterministic wallet like Armory.  There is no keypool.  The seed derives every address that has ever been used and will ever be used.  Change addresses are just pulled as the next address in this infinite chain that are all saved on your print-once paper backup.

Deterministic wallets are coming to other clients.  But Armory and Electrum already use them.  And even so, you should never have to worry about change.  Ever.  Unless you're manually constructing transactions yourself, in which case it's very easy to shoot yourself in the foot.  Established Bitcoin clients have this covered, and mostly transparently.

Forgive me if this is a ludite question, but I found out today that the bitcoin-qt client is storing btc in background 'change addresses' when i send out amounts from the wallet to other addresses?

If this is true, then my thinking that my offline wallet.dat that is my backup of my balance, is not really a backup of anything at all.

Is this expected behavior?  If its true, then i have to backup my wallet.dat everytime i spend anything so its consistent?  This seems insane... hard drives fail all the time.  If a hard drive fails right after i perform a send, i lose all my remaining BTC because it is in a hidden 'change address'?

Someone please tell me I'm wrong.. if I'm not, this is a massive problem.  can the behaviour of -qt be changed to eliminate this behavior?

Thanks, and sorry if I'm wrong here, but this is my understanding of how the client works from reading documentation..

edit: Sorry, further research does answer my question affirmatively.. this is just how it works.  With that in mind, does anyone else see an issue here with something like a hard drive failure upon send?  How would one reclaim their BTC if this happened?  Search for the change address in blockchain, and then how to unlock it?  Would it use same private key as the address you originally sent from?  I'm curious how others guard against this, and feel confident in thier offline backups if the backups themselves are unaware of change addressees..