A few technical questions about the wallet.dat

[zipslack]

I'm new to bitcoin and I have a few questions I hope someone can answer. I've been reading everything I can find but it seems like a lot of the documentation and technical information is scattered in many different places, so I apologize if these have been answered before. If you have a link to any relevant information I might have missed please let me know.

I'm a little confused about how things work with the wallet.dat file. I've read that it needs to be backed up frequently and that it contains 100 pre-generated keys which are used up by transactions, so that a new key is generated after each transaction. I've also read that your bitcoin addresses can receive payments while the bitcoin client isn't running. To me that seems like it contains some internal contradictions but that might just be my ignorance. Is there a limit on the number of payments you can receive while the client isn't running? For example if you receive more than 100 payments will you run out of keys, or is it OK because the client will just generate new ones as it processes the transactions once you finally run it? Are those 100 keys published into the network at all, or just stored in the wallet?

Can I run clients on multiple computers simultaneously using the same wallet.dat?

Secondly, I'm given to understand that all transactions in the bitcoin network are public, that the block chain effectively contains the complete ownership history of each coin since it was created. So, how can I examine that history? I thought there might be something like this in the RPC API but the documentation doesn't mention it. Is there software that does this? Or am I confused about how this actually works?

[asdf]

You can receive transactions while your client is offline because they get stored in the block chain which you will download and check. All you need is your private key, which lies in your wallet.dat file.

However, if you lose the .dat file, you lose the private key and therefore, cannot claim your transaction. This is why people want to pre-generate a bunch of keys to put in their backed up wallet, so that even if you lose your wallet, you can still reclaim your lost coins because the private keys your receiving with are in the backup.

In short: you don't want to be sent transactions to keys that you haven't backed up. Anyway, I think that's how it works.

I think there is also an issue with sending transactions and backups.

[zipslack]

You can receive transactions while your client is offline because they get stored in the block chain which you will download and check. All you need is your private key, which lies in your wallet.dat file.

However, if you lose the .dat file, you lose the private key and therefore, cannot claim your transaction.

That doesn't really make sense. If there was only one private key you'd only have to back it up once, not after every transaction.

In short: you don't want to be sent transactions to keys that you haven't backed up.

That implies that the keys which are pre-generated are being published into the network (or rather, the public half of a public/private keypair) so that when a client sends you a payment, it needs to get a current key for your address to send to. Can anyone confirm whether or not that's correct?

[theymos]

See http://www.bitcoin.org/wiki/doku.php?id=backup

All transactions to a particular Bitcoin address are to one key. Once you create the address (key), your wallet will always contain the necessary information to receive using that address. Somewhat counter-intuitively, receiving with a Bitcoin address is one of the few activities that does not require backing up your wallet.dat.

Secondly, I'm given to understand that all transactions in the bitcoin network are public, that the block chain effectively contains the complete ownership history of each coin since it was created. So, how can I examine that history?

You can use Bitcoin's -printblock or the getblock patch for RPC. See these wiki pages for some necessary background info:
http://www.bitcoin.org/wiki/doku.php?id=block
http://www.bitcoin.org/wiki/doku.php?id=transactions

I'm making an easy-to-use web tool for looking at this data.

[zipslack]

Thanks for the info, theymos. After reading the backup wikipage a few things make sense but I have a new question. To quote the page, "Bitcoin stores 100 queued addresses in wallet.dat. Once you use them all, a backup is necessary. All of the actions above use an address." So, if I understand correctly, an address can receive many payments but only send one? Or does the term 'address' mean something else in this context?

Attempting to answer my own question regarding running multiple bitcoin clients using the same wallet.dat, it seems that this would work until one of the actions listed on the backup wikipage takes place. Then the wallets would diverge and one of them would become invalid. (Or at the very least, they would contain pre-generated addresses that aren't identical, and once those addresses are used something bad would happen.)

[theymos]

So, if I understand correctly, an address can receive many payments but only send one?

No. The address is "used" in the sense that it is removed from the pool and put into the wallet proper. The addresses can be used for unlimited sending and receiving.

Nearly every time you send bitcoins, you also end up creating a brand new address and sending some "random" number of bitcoins to it (back to yourself). This new address takes one address from the pool, puts it into the regular section of the wallet, and generates a new address to "top off" the pool. Wallet backups are good for only 100 "new address actions" because addresses generated after that will not be in the old wallet.

Back up your wallet. Hit "New Address" 100 times. All of those addresses are in the backup. Create one more address and you've created an address that's not in the backup -- it will be lost if you restore from the backup.

Attempting to answer my own question regarding running multiple bitcoin clients using the same wallet.dat, it seems that this would work until one of the actions listed on the backup wikipage takes place. Then the wallets would diverge and one of them would become invalid. (Or at the very least, they would contain pre-generated addresses that aren't identical, and once those addresses are used something bad would happen.)

They would diverge after a new address action, though this would only become apparent after their pools are exhausted. They'll both be able to see and spend transactions sent from and to the addresses that they share (current addresses + 100 pooled addresses). Bitcoin will synch their shared transactions to some degree by looking at the block chain, but this is not an intended use of Bitcoin and you will run into occasional errors.

[zipslack]

Thanks for your help, theymos.