Need help understanding a transaction case

[JollyGreen]

So, I'm working on adding code to bitcoin that allows users to send from specific addresses.  I have it flushed out but running into some issues.  It has takin me a while to properly form the question for the problem I'm running into which relates to understanding how bitcoin handles the below situation:

In the un-modified bitcoin, I'm not sure how the below is handled

*** transaction 1 ***
Say you have 50 BTC in your account from 1 generation
you use "sendfrom" to send 1 BTC to another account you own
this creates a transaction with 1 input and two outputs
50 btc as the input, call this address A
49 btc as change (from a somewhat random address or group of addresses you own to a hidden address) call this address U
1 btc to the address you specified, call this address B

When transaction 1 is commited, I believe the input transaction is marked as spent, in this case, it's fine because 50btc was the only output of a previous transaction that is connected to the input of my "Transaction 1"

*** transaction 2 ***
So now I want to spend say 0.5 BTC.
The software only has two addresses it can possibly select 0.5BTC from, "U" and "B".
So it selects one of these outputs from Transaction 1 as the input for Transaction 2
creates a change output for transaction 2 called U2
sends 0.5BTC to my desired address C

This is where I think I'm missing something, because it seems to me that when transaction 2 is commited, it would mark transaction 1 as spent, but transaction 1 still has an unused output that is ours and is not spent.  I've looked thru the code I don't know how many times and I can't figure out how this case is handled.  Can someone point out my flaw?

[1713468616]

1713468616

[theymos]

Right. See:
http://bitcointalk.org/index.php?topic=3759.0

[Hal]

It's an artifact of the coin choice algorithm, not an inherent property of transactions. Sipa offered a patch in that thread, but I don't know what it does.

[theymos]

The wallet database marks entire transactions as spent? That would explain why SelectCoins chooses coins like that...

[caveden]

The wallet database marks entire transactions as spent? That would explain why SelectCoins chooses coins like that...

Yeah, it seems wallet database does mark entire transactions as spent, should we consider updating the database code to mark outputs as spent rather than transactions?

Even that sounds too much... I mean, why can't you spend part of an output today an another part of it tomorrow?
This would be a way of stop using this change thing (which I never really understood the reason to exist), and minimizing transaction sizes...

[Pieter Wuille]

The wallet database marks entire transactions as spent? That would explain why SelectCoins chooses coins like that...

Yeah, it seems wallet database does mark entire transactions as spent, should we consider updating the database code to mark outputs as spent rather than transactions?

That is exactly what my patch does (I needed spent-per-txout for another purpose, but as it enabled better selection of imputs for transactions, it's implemented too): https://github.com/bitcoin/bitcoin/pull/116

[Hal]

Even that sounds too much... I mean, why can't you spend part of an output today an another part of it tomorrow?

The unit of spending in Bitcoin is the output of a transaction. That's the closest thing in the system to a "coin".

[Jim Hyslop]

A transaction is the collection of all input bitcoins and all output bitcoins. So a transaction never gets spent - only the bitcoin outputs get spent, when they are used as an input to a new transaction.

Re-using your first example: if you have a bitcoin worth 50BTC and want to give me 1 BTC, the transaction consists of a total of three bitcoins: one 50BTC in, one 1BTC out and one 49BTC out. At that point, the 50BTC coin has been spent. I can then spend my 1BTC, but your 49BTC is unaffected.

Now, refresh my memory - why do you care exactly which bitcoin gets spent? I mean, if I have a bunch of dollar bills in my physical wallet, I don't select one based on its serial number, I just pick one and use it. ISTR there is a discussion on this topic, so feel free to just point me to the discussion.

[Jim Hyslop]

Even that sounds too much... I mean, why can't you spend part of an output today an another part of it tomorrow?
This would be a way of stop using this change thing (which I never really understood the reason to exist), and minimizing transaction sizes...

OK, and how would that system work? You have a token (a bundle of bytes, maybe a Bitcoin, maybe some other system) that is worth 50 units. You want to give me one unit and keep 49 units. How do you make that work? I can't, offhand, think of any system that would even approach the simplicity and resistance to attacks that Bitcoin does.

[Gavin Andresen]

Now, refresh my memory - why do you care exactly which bitcoin gets spent? I mean, if I have a bunch of dollar bills in my physical wallet, I don't select one based on its serial number, I just pick one and use it.

You might care if you got the dollar bill from somebody you suspect is working for the Secret Police, you think think the Secret Police might be trying to trace payments by recording bill serial numbers, and you're spending the dollar to pay a local print shop to produce some illegal Subversive Propaganda.

That's roughly similar to tracing bitcoin transactions.

[Hal]

One case to consider is when you have addresses A and B in your wallet but don't want them linked. Jollygreen's code will allow making sure you never spend from A and B together, I think, so that's good.

But suppose someone uses the multipay patch to send to both A and B together, because they suspect that the addresses are linked. There are a few ways this could go wrong. Suppose he told you he was sending 10 to A, but also includes 1 to B in the transaction. I'm not sure what the client would do, but it might show you receiving 11. Then you'd be like, dude, you sent me 11 not 10. And he'd be like, you're busted.

Another way it could go wrong is that you could spend them together, and again, you're busted. I think Jollygreen is protecting against this.

Yet another failure mode would make it impossible to spend the funds, because it would break the rules. So sipa's patch needs to be part of this, allowing the outputs to be split.