Why can't the change be returned to itself?

[oOoOo]

Why is it necessary to utilise a new address in my wallet as a return for my change? Why is it not possible for an address to send the change back to itself??
This is headache inducing...

Is there some kind of conflict? Time delay?? What is it?

..Wait! I got more:

What happens if I used up all 100 preset receive addresses of my wallet when making a transaction? Does the client create another 100 new addresses, or just one? Or does it reuse an old one from my wallet??

Anyone?

[Meni Rosenfeld]

I think it's about anonymity, by creating a new address, an observer doesn't know which output is the recipient and which is the change.

The client always maintains a buffer of 100 addresses, when one is used another is generated.

[Pieter Wuille]

If it were to reuse addresses for change, it would be trivial to find out which of both outputs is change and which is payment.

And a new reserve address is generated each time one is used.

[theymos]

It's not required by the network for change the go to a new address. The client just does it to improve anonymity.

Whenever an address is removed from the pool, the pool is re-filled to 100. So if you take 10 addresses from the pool, 10 more will be generated to bring the pool back to 100.

There's no way to generate more than one address per transaction with the default client

[oOoOo]

So when somebody downloads the client the very first time, and the wallet is created, how many private keys are included in this very first instance?
Is it immediately filled up with 100 or are there no addresses stored at all? Or just one??

Can you please give me the name of the function that does this^^ I'd like to look it up in the code!

Does the client check the # of total addresses with each transaction, or one in a specific time-frame?

Thanks in advance to anyone who can help!
.

[error]

The very first Bitcoin transactions did send change back to the original input address (example). As theymos mentioned, this was changed early on to help improve privacy.

The first time you run Bitcoin, it generates your pool of 100 addresses.

[randomguy7]

Is it possible that the key pool is only synced with the wallet.dat after about 15 keys in the key pool got replaced by new ones?
I did some playing around in testnet. When performing lots of send transactions, it takes about 15 transactions till I see a change in the wallet.dat file size.

[Furyan]

Is it possible that the key pool is only synced with the wallet.dat after about 15 keys in the key pool got replaced by new ones?
I did some playing around in testnet. When performing lots of send transactions, it takes about 15 transactions till I see a change in the wallet.dat file size.

That is likely due to disc flushing.  When an fwrite is made to a file, the bytes aren't actually always written to disc until the block size limit is reached or exceeded - the data is kept in memory until that happens.

It is likely taking a number of transactions before the file system decides to flush the written data to disc.

This is, incidentally, how data loss normally occurs - unflushed data doesn't get written to disc before the process exits and is lost. 

[randomguy7]

Is it possible that the key pool is only synced with the wallet.dat after about 15 keys in the key pool got replaced by new ones?
I did some playing around in testnet. When performing lots of send transactions, it takes about 15 transactions till I see a change in the wallet.dat file size.

That is likely due to disc flushing.  When an fwrite is made to a file, the bytes aren't actually always written to disc until the block size limit is reached or exceeded - the data is kept in memory until that happens.

It is likely taking a number of transactions before the file system decides to flush the written data to disc.

This is, incidentally, how data loss normally occurs - unflushed data doesn't get written to disc before the process exits and is lost. 

Yes but it should anyways show the new file size, no matter if it's already synced to the disk.

[wolftaur]

[Yes but it should anyways show the new file size, no matter if it's already synced to the disk.

Assuming a UNIX system, that's true with write() because once the kernel has returned from write(), the data is in filesystem buffers whether or not it has been flushed to disk -- thus, disk structures are already at least queued for update. fwrite(), however, implements its own layer of buffering in addition to the buffering in the kernel. fwrite() called repeatedly with tiny amounts of data to append will use its own memory to buffer it to at least one disk block, to avoid a context switch into the kernel. Since the kernel has no idea how much (if any) such data is buffered, it doesn't report it when you ask about file size.

[FreeMoney]

It would be cool to modify the client to use 1 new change address when the amount sent is roughly half of what was in an address, 2 new addresses when it's roughly a third, etc. The change amounts should be random but roughly equal. This would make it really hard to guess any better than chance. Also putting a way to SendMany in the main client would let people obfuscate even more by making designer transactions.

[cunicula]

Are there extra bandwidth and storage costs associated with generating new addresses? If so, in percentage terms, how much bandwidth/storage could you save by returning change to the original address?

I am wondering, for example, if it makes sense to impose fees for returning change to a new address.

[JoelKatz]

Are there extra bandwidth and storage costs associated with generating new addresses?

No.

If so, in percentage terms, how much bandwidth/storage could you save by returning change to the original address?

None. Changing one string to another doesn't save anything.

I am wondering, for example, if it makes sense to impose fees for returning change to a new address.

Since you can't tell that's what's happening, there's no way you could do this. The whole point of using a different address is to make it impossible to know that it is change being returned to the same person.

[cunicula]

Are there extra bandwidth and storage costs associated with generating new addresses?

No.

If so, in percentage terms, how much bandwidth/storage could you save by returning change to the original address?

None. Changing one string to another doesn't save anything.

I am wondering, for example, if it makes sense to impose fees for returning change to a new address.

Since you can't tell that's what's happening, there's no way you could do this. The whole point of using a different address is to make it impossible to know that it is change being returned to the same person.

Thanks for the answers. I'm sure this is basic, but how are new addresses associated with each wallet without requiring the transmission and storage of additional information?

[JoelKatz]

Thanks for the answers. I'm sure this is basic, but how are new addresses associated with each wallet without requiring the transmission and storage of additional information?

They're not. It's a bit complicated to explain, but let me go into enough detail to give you a very clear understanding:

First, to generate a bitcoin address, you generate a random 256-bit key. This you keep secret, store in your wallet, and never tell anyone. You then perform a mathematical operation that is irreversible that converts this key into a bitcoin address. You then tell people your address. When they send money to you, they put your address in the transaction as the recipient.

When you go to claim bitcoins, say to spend them, you take that 256-bit key you generated and use it to produce a signature to claim the bitcoins. That signature goes into the transaction and proves that you know the 256-bit key that corresponds to that bitcoin address.

Essentially, when you send money to an address, you're just putting a transaction in the blockchain. The address only determines what 256-bit key you need to claim the coins when you eventually do so. If you send me ten transactions all to the same address and then I claim them, the process is precisely the same as if you send them to different addresses and then I claim them. You still send each transaction, I still claim each one. An address sitting in a wallet is completely passive until it is used to claim a transaction.

Say I have 10 bitcoins sent to address A and want to send 5 bitcoins to your address B. I generate a new address C, pull in the 10 bitcoins from A, send out 5 to B and 5 to C. There is no difference to the network between my sending the 5 bitcoins "change" to C or to A. It's the same transaction and the same effort to claim it (just using a different key). The only difference is, by sending 5 bitcoins back to A, you can tell which 5 bitcoins are being paid and which are the change.

[oOoOo]

It would be cool to modify the client to use 1 new change address (...)

It would be cool if all of this was completely user configurable. But I guess a man can dream now, a man can dream....
.

[ribuck]

It would be cool if all of this was completely user configurable. But I guess a man can dream now, a man can dream....

Or a man (or woman) can post a bounty for a developer to enhance the software.