<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2014-07-18T06:29:03.840Z
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
CC BY-SA 3.0
2014-07-19T07:29:24.743Z
I prefer the multibit approach to saving wallets, it's more efficient in the file structure manner and also better for recovery.
Shayan
CC BY-SA 3.0
2014-07-18T04:10:11.197Z
2014-07-18T04:10:11.197Z
Shayan
<p>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 <code>listtransactions</code>. Reconstructing this data from the block chain is <em>extremely</em> 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.</p>

CC BY-SA 3.0
2014-07-18T05:31:14.320Z
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
CC BY-SA 3.0
2014-07-18T05:48:05.983Z
@linhares Your keys change after every outgoing transaction anyway because Bitcoin Core needs to generate a new change address.
theymos
CC BY-SA 3.0
2014-07-18T05:50:11.260Z
Of course, but incoming txs also seem to change the hash of wallet.dat.  Hence my question.
linhares
CC BY-SA 3.0
2014-07-18T04:50:49.660Z
2014-07-18T04:50:49.660Z
theymos
<p>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.  </p>

<p>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?</p>

<wallet><wallet.dat>
Bitcoin core: why does the wallet file contain transactions?
linhares
# Bitcoin core: why does the wallet file contain transactions?

(Asked by: username_0 on 2014-07-18)

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?

**Tags:** wallet, wallet.dat


---

## 2 answers

### Answer by username_2 on 2014-07-18. Score: 5 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  
> **username_2**: @username_0 Your keys change after every outgoing transaction anyway because Bitcoin Core needs to generate a new change address.  
> **username_0**: Of course, but incoming txs also seem to change the hash of wallet.dat.  Hence my question.  

---

### Answer by username_1 on 2014-07-18. Score: 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.

> **Comments:**
> **username_0**: 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).  
> **username_1**: I prefer the multibit approach to saving wallets, it's more efficient in the file structure manner and also better for recovery.  

---

