1

I really don't understand why the strong coupling here. I mean, whenever I go and make a backup, if there's a new transaction involved, the hash of the backup changes.

I wonder why this is. And furthermore, wouldn't it be 'better' (or what is lost?) by having a loosely-coupled transactions file that wouldn't change a bit after a transaction?

5

You can't spend bitcoins without having the transactions in which you received the bitcoins. Bitcoin Core also needs to actually know about your transactions to display them with RPC commands like listtransactions. Reconstructing this data from the block chain is extremely slow. Try running Bitcoin with the -rescan switch, which searches the entire block chain for wallet transactions: it often takes 15 minutes or more. Sites like blockchain.info can only get info about addresses and transactions quickly because they maintain huge indexes of addresses/transactions, but Bitcoin Core does not maintain such indexes. Also, it is very likely that Bitcoin Core will eventually start throwing away most block chain data to save disk space. If this happens, then you will be unable to recover your wallet transactions without downloading a big chunk of the block chain again. So saving these transactions is in fact pretty important, and they should be backed up along with your keys in wallet.dat.

  • Interesting. So the tradeoff is performance versus a strong coupling of addresses/transactions. Using and backing up files for some years, I wish we could have separate wallet files from transactions, so that the hash in wallet.dat would only change if something regarding the priv keys had changed. – linhares Jul 18 '14 at 5:31
  • 1
    @linhares Your keys change after every outgoing transaction anyway because Bitcoin Core needs to generate a new change address. – theymos Jul 18 '14 at 5:48
  • Of course, but incoming txs also seem to change the hash of wallet.dat. Hence my question. – linhares Jul 18 '14 at 5:50
2

It needs the transactions for faster outgoing transactions. What I mean is that to broadcast a new transactions the transactions that involved the bitcoins being sent should be included in the script of the raw transaction so it needs to store them somewhere to be able to include them in the raw transaction.

It is possible to have them in a separate file or not to store them at all but this is how it has been implemented for better performance.

  • I see, thanks! I still wish the files were separate. New users will find it strange that receiving tx-in will change the hash of the wallet.dat (and make it seem as if a backup is outdated or corrupted). – linhares Jul 18 '14 at 6:29
  • 1
    I prefer the multibit approach to saving wallets, it's more efficient in the file structure manner and also better for recovery. – Shayan Jul 19 '14 at 7:29

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.