Yet another dumb question

[AliceWonder]

Sure it has been asked before and maybe in a FAQ but I'm having trouble finding.

I understand the way sending works is the wallet looks for smallest addresses that cover payment.
They all become part of the transaction, but everything in those addresses is sent and the change is returned to a fresh address.

So if I have 7 BTC in one address and 11 BTC in another and I buy something that costs 14 BTC, both addresses are emptied and 4 BTC is sent to fresh address in the wallet, 4 BTC that is mine but can't be spent until the confirmations are done, correct?

But if I send 8 BTC, will it use the 7 and 11 and return 10 or will it leave the 7 alone, send the 11 and return 3 ??
That's what I suspect (the latter), that's logical as it doesn't then freeze ability to spend from the 7 until confirmations are done.

But will that eventually end up with a bunch of addresses that all have tiny amounts building up? Is there a way to consolidate these tiny amounts into a single address, say, whenever their sum reaches 0.5 BTC ??

[dbkeys]

Interesting questions. I'm sure that if you have several addresses with small amounts you can pay them all to yourself into another address (perhaps at another device) to consolidate them. I would agree that it is preferable to not put your funds into "transaction limbo" for even a few minutes if its not necessary.  I have heard the Armory client has more features. It might let you choose which addresses to take funds from, but I haven't checked it out myself. https://bitcoinarmory.com/

[Fiyasko]

Pffbfbbfb what the heck is going on, Since when can the bitcoin wallet system----- OHHHHHHhhhhhhhhhhh I am so fucking stupid
If the 7btc and 11btc are in the same wallet.dat, Then there will not be a "refund transaction" we'll call it, of 4btc  the 7 btc address will be depleted to zero, and the 11btc address will lose another 7btc to complete the full amout, Leaving you with 4btc in your 11btc address.

It will always deplete the smaller btc amount address first (from what i've experianced from using the bitcoin-qt wallet, This is not fact)

[AliceWonder]

Pffbfbbfb what the heck is going on, Since when can the bitcoin wallet system----- OHHHHHHhhhhhhhhhhh I am so fucking stupid
If the 7btc and 11btc are in the same wallet.dat, Then there will not be a "refund transaction" we'll call it, of 4btc  the 7 btc address will be depleted to zero, and the 11btc address will lose another 7btc to complete the full amout, Leaving you with 4btc in your 11btc address.

It will always deplete the smaller btc amount address first (from what i've experianced from using the bitcoin-qt wallet, This is not fact)

Then I'm not understanding something, because from what I read, someone had 900 BTC and send himself 1 and restored his drive, resulting in a 899 loss because he hadn't backed up the key generated to receive the 899 that was change for sending himself 1.

So has the protocol changed or did I not understand what happened?

[Open4lies]

the way bitcoin-qt uses inputs is not much predictable by my experience. It tries to join many small old inputs and dont care about fees

[mprep]

the way bitcoin-qt uses inputs is not much predictable by my experience. It tries to join many small old inputs and dont care about fees

Yeah, probably that's true.

[niko]

Pffbfbbfb what the heck is going on, Since when can the bitcoin wallet system----- OHHHHHHhhhhhhhhhhh I am so fucking stupid
If the 7btc and 11btc are in the same wallet.dat, Then there will not be a "refund transaction" we'll call it, of 4btc  the 7 btc address will be depleted to zero, and the 11btc address will lose another 7btc to complete the full amout, Leaving you with 4btc in your 11btc address.

It will always deplete the smaller btc amount address first (from what i've experianced from using the bitcoin-qt wallet, This is not fact)

This is completely wrong.

Question from OP is a good one, and different client software deals with it differently. It has nothing to do with Bitcoin protocol.  The issue of fragmentation/consolidation  has been on developers'  minds, just search the project development board.

[Foxpup]

They all become part of the transaction, but everything in those addresses is sent and the change is returned to a fresh address.

Close. However, instead of addresses, it is previously received transactions that have to be spent in their entirety. eg, if you received BTC3 in one transaction and BTC4 in another transaction to the same address, each of those amounts would be treated separately (eg, you could send BTC2 and receive BTC1 change) even though they are at the same address.

So if I have 7 BTC in one address and 11 BTC in another and I buy something that costs 14 BTC, both addresses are emptied and 4 BTC is sent to fresh address in the wallet, 4 BTC that is mine but can't be spent until the confirmations are done, correct?

This is something that varies between wallets. While some work as you describe, others (including Bitcoin-Qt) do not actually require confirmations before change can be spent. There is no technical reason to wait for confirmations before sending coins, however unconfirmed transactions usually can't be trusted to not be double-spent. But since change is sent from yourself, to yourself, it is always trustworthy (unless you're trying to rip yourself off).

But will that eventually end up with a bunch of addresses that all have tiny amounts building up?

No. Think about what would happen if you did have a bunch of tiny amounts built up, and tried to spend them. Say you have BTC10 in ten lots of BTC1, and you want to send BTC4.5. You would take 5 of those BTC1 (and the recipient receives a single BTC4.5, so the individual BTC1 units don't exist anymore) and you would get a single BTC0.5 in change. About half of your "dust" is suddenly gone. The more "dust" you have, the more likely it is that a future transaction you send will consume a large chunk of it in this way.