some questions about -keypool=<x>

[jonathan]

when i check the balance of any address at the following url:
http://blockexplorer.com/address/<address_goes_here>

... i see the following text appearing in the web page:
"Every time a transaction is sent, some bitcoins are usually sent back to yourself at a new address (not included in the Bitcoin UI), which makes the balance of a single address misleading."

Q1) Does this mean the btc "sent back" are sent back to one or more of the other addresses contained in the sender's wallet.dat file?

If the answer to Q1 is "yes", then please suppose for a moment that the wallet.dat was generated with this entry in bash:
./bitcoin -keypool=0
... and then:
chmod 400 /path/to/wallet.dat

... which generates a rather skinny ~16kb wallet.dat containing only one address, as far as i can tell. (A standard issue wallet.dat is around 90kb at generation.)

Q2) If i send from this one-only-addy-wallet.dat, will the btc "sent back" be sent back to the one and only address without a hitch?

I can't see why they wouldn't, but maybe someone else can see something i can't. I hope this is not too arcane a question! Thanks for considering this.

/** edited to include chmod

[Maged]

The keypool can only be used to pregenerate future keys. Setting it to zero means that you're change will be sent to an address that previously would not have been in your wallet. It won't disable the creation of keys.

All of this nonsense should be resolved once we switch to using deterministic keys that have the anonymity benefits of using a new key, but also the benefits of only having to back up your wallet once.

[JoelKatz]

No, they won't. A new address will be generated and added to your wallet. When you're archiving a wallet file, you want it to contain as many spare addresses as possible, not as few. A size of 0 means 0 extra keys will be generated -- keys will only be generated when needed.

[hugolp]

No, they won't. A new address will be generated and added to your wallet. When you're archiving a wallet file, you want it to contain as many spare addresses as possible, not as few. A size of 0 means 0 extra keys will be generated -- keys will only be generated when needed.

Note that he said that he is protecting wallet.dat making it only readable (chmod 400 /path/to/wallet.dat). How would the client would react if it cant modify wallet.dat?

[jonathan]

Maged and JoelKatz,

So sorry about the late edit of my question. I suppose you both answered before the "$ chmod 400" bit reared its ugly head.

As to *why* i would only one addy at this particular wallet, i just wanted to be able to reliably use the http://blockexplorer.com/address/<address_goes_here> page to keep tabs on this wallet, without having to decrypt and mv a wallet.dat, and then start up a client just to find out how much btc i have got. Having a read only wallet.dat containing just one keypair should do for this, or so i reckon. If i have several addresses in the one wallet, then the web page method of btc balance checking is torpedoed. But if i were to go this one-address only route, i have the worry about the btc "sent back". (In addition to whatever other horrors may await me!)

Again, sorry about the late edit to the original post.

[theymos]

Note that he said that he is protecting wallet.dat making it only readable (chmod 400 /path/to/wallet.dat). How would the client would react if it cant modify wallet.dat?

It'd crash. There's no way to force the client to use just one address without modifying the code.

[JoelKatz]

Note that he said that he is protecting wallet.dat making it only readable (chmod 400 /path/to/wallet.dat). How would the client would react if it cant modify wallet.dat?

One would hope it wouldn't do the transaction. If it did the transaction, you'd never be able to claim the coins unless the key happened to still be in memory.

[jonathan]

Thanks for the input Theymos, i didn't think it would be a crashing big a deal :-O

JoelKatz, i didn't quite follow who was claiming and who was sending in your last post. So just for sh*ts and giggles--and notwithstanding Theymos's decisive contribution--here's an example:

Bob has 10btc held at a one-address-only, read-only wallet.dat. With this address, Bob wants to send 1btc to Alice. Surely Bob's client gets RAM to load Alice's pubkey, uses Alice's key to encrypt the string for the 1btc (and whatever else for the btc to be "sent back"), and then sends this to Alice, right? If Bob tries this (and has hacked his client so it won't crash), then surely his old balance of 10btc will after a confirmation show up on the blockchain as now being 9btc (assuming there are indeed no problems with the btc "sent back"). If all Bob wants is for a full account of the change of balance on his address to show up in the blockchain, then no writing needs to be done at his actual wallet.dat.

Even if (as Theymos said) Bob's client crashes, nevertheless, the blockchain might still record things faithfully once the string is encrypted and sent to Alice. Of course, in the real world, it would be a little impolite to go around crashing one's client, so one wouldn't do it. I'm just hypothesising really.

Crap. I have a feeling i'm waaaay out of my league here. If there is *so much* wrong with that example above, then i hope it at least gets your week off to a lol start ;-) Anyhow, i definitely won't be doing any chmodding now.

[kjj]

You are making the very common mistake of thinking in terms of addresses.

Addresses do not have balances.  Spends do not come from addresses.

Spends come from transaction outputs.  Transaction outputs must be redeemed all at once, never partially.

In your example, if you have a balance of 10 btc and you send 1, your client will look through the list of transaction outputs that it has the keys for and it will select a subset of those outputs that adds up to at least 1 (the amount you want to send).  It then makes a new transaction using that entire subset as the input, and with 2 outputs*:  one for the recipient, and the other for the change.  In the client as it is today, the change always goes to a fresh key (address).  If the client can't find a spare key in the wallet file, it creates a new one.  If it can't write that new key to the file, you just lost whatever the change would have been.  If your 10 btc balance had been from a single transaction, you just lost 9 btc.  Forever.  If the client crashes too, that was just a bonus.

Come up with a better way to track your balance.

* I'm ignoring two special cases that don't really change the process much.  The first is if the client just happens through random luck to find exactly the right amount so that it doesn't need to make any change.  The other is if transaction fees are needed.

[natman3400]

You are making the very common mistake of thinking in terms of addresses.

Addresses do not have balances.  Spends do not come from addresses.

Spends come from transaction outputs.  Transaction outputs must be redeemed all at once, never partially.

In your example, if you have a balance of 10 btc and you send 1, your client will look through the list of transaction outputs that it has the keys for and it will select a subset of those outputs that adds up to at least 1 (the amount you want to send).  It then makes a new transaction using that entire subset as the input, and with 2 outputs*:  one for the recipient, and the other for the change.  In the client as it is today, the change always goes to a fresh key (address).  If the client can't find a spare key in the wallet file, it creates a new one.  If it can't write that new key to the file, you just lost whatever the change would have been.  If your 10 btc balance had been from a single transaction, you just lost 9 btc.  Forever.  If the client crashes too, that was just a bonus.

Come up with a better way to track your balance.

* I'm ignoring two special cases that don't really change the process much.  The first is if the client just happens through random luck to find exactly the right amount so that it doesn't need to make any change.  The other is if transaction fees are needed.

In the spirit of this, why not rig it to send the spare change back to the same address instead of a new one? Should be feasible with a little tinkering, unless im overlooking something.

[kjj]

If you send the change back to one of the input addresses, you end up being a tiny bit less secure, and quite a bit less semi-anonymous.  And you really gain nothing by doing it that way.  Keys are small, and tracking many of them is not hard.

What people really should be asking is how they can make the client look for inputs that allow the spend and the change to be roughly the same size, to make it harder for a snooper to tell which was which.

[jonathan]

wow, thanks for your post kjj, that was very informative.

[jimbo77]

What people really should be asking is how they can make the client look for inputs that allow the spend and the change to be roughly the same size, to make it harder for a snooper to tell which was which.

That is a good idea!

[JoelKatz]

In the spirit of this, why not rig it to send the spare change back to the same address instead of a new one? Should be feasible with a little tinkering, unless im overlooking something.

Two reasons:

1) Same address as what? The coins being sent out come from transaction outputs.

2) That would disclose which output is the 'change' and therefore, by process of elimination, which output(s) are to the recipient(s). This is information the client can easily conceal.

Part of this problem is that the bitcoin system thinks of coins as belonging to transaction outputs, the client thinks of coins as belonging to accounts, and humans think of coins as belonging to addresses.