Why was this transaction structured this way?

[BeeCee1]

I was looking on block explorer and I saw this:
http://blockexplorer.com/tx/1dc3384e7ffedf0036b0fd269f3fe46fb08e8c1436bb11f9d083e236cd0f620f

Two inputs, one 5.87BTC and one 10BTC.  Then, two outputs, one for  10BTC and one for 5.87BTC.  Obviously, this transaction could have been a single input and a single output.  Is there any reason why it would be better to have two inputs instead of one, or is it just a bit of brain-deadness on the part of bitcoin?

[1713513750]

1713513750

[1713513750]

1713513750

[1713513750]

1713513750

[1713513750]

1713513750

[Gavin Andresen]

Looks like somebody's playing with a tweaked bitcoin-- if you trace back the inputs they're from a previous block that has the same odd pattern.

The standard coin selection algorithm in bitcoin would generate a one input / one output transaction.

Hal and theymos are right-- I misremembered how the coin selection algorithm works.

[BeeCee1]

Here's a couple more transactions of the same nature:
http://blockexplorer.com/t/9Z4YgzGqgT   IN: 0.5 and 0.5 OUT: 0.5 and 0.5 (block 109801)
http://blockexplorer.com/t/4B3i2NQWNM  IN: 0.02 and 1.02 OUT: 0.02 and 1.02 (block 109779)

[Hal]

I don't think it's happening here, but I had something similar happen when I paid myself.

Suppose you have a wallet funded only with one 15.87 btc transaction, and you pay yourself (ie one of your wallet addresses) 10. Then you will have two funded addresses in your wallet, the 10 you paid, and one with 5.87 for change. Now suppose you pay someone else 10. You'd think it would just use the 10 btc address as input. But it won't.

The client will choose both the 10 and 5.87 addresses as input, and have two outputs, 10 btc to the address you are paying, and 5.87 back to you as change. The reason is the client's coin-choosing algorithm is transaction based. If you have transaction where both outputs go to you, as when you pay yourself, then if the client payscwith that transaction, it will always use both addresses.

So this is a way you can get transactions like what you saw, with two inputs and two outputs, and values that match.

[Hal]

Actually I was wrong, this is exactly what is happening here. You see that both inputs come from the same transaction. In these cases, the pay-yourself cycle was repeated, and you again end up with two addresses in the same wallet, funded by the same transaction, which must be used together.

[caveden]

Wouldn't it be better for the network if the client tried to minimize transaction sizes? (for the network and for the user, as soon as we have to pay for transactions...)

Actually, talking about it, why does the change mechanism exists? Is it to improve anonymity? It's not very clear to me how does the change improves anonymity, but anyway, if that's the case, I'd suggest to make it optional, and disabled by default. Only those really worried with anonymity would activate it. That would make transactions smaller.

[Cdecker]

Well,  there may be several optimization targets. One is what you described to minimize the number of inputs to reduce the transaction size. Another may be to use the smallest possible inputs which increases transaction size but also reduces the number of inputs we have to track (long term optimization). And finally we could try to use the oldest inputs which would allow the network to Stub off old blocks since the only useful information we can get from it is its hash which has been confirmed.

I'm not sure yet which one is best

[theymos]

The standard coin selection algorithm in bitcoin would generate a one input / one output transaction.

Not true. Bitcoin does this sort of thing all the time. Here's a Bitcoin Faucet transaction that does it:
http://blockexplorer.com/tx/863d906463c3b5c24e76ebc04539f7ae33e3e55efab9affb15eb4379487d9e3c

I've noticed that Faucet transactions are especially prone to this, so it might be more likely with small amounts.

(Edit: Hal's explanation fits. People must be sending Faucet coins to the Faucet.)

[caveden]

Well,  there may be several optimization targets. One is what you described to minimize the number of inputs to reduce the transaction size. Another may be to use the smallest possible inputs which increases transaction size but also reduces the number of inputs we have to track (long term optimization).

I'm not sure I understood this "long term optimization". By smallest I believe you mean in BTC amount, right? The goal would be to spend smaller addresses quicker in order to have less addresses with money in it, is that it?
Besides shrinking people's wallets, what optimization could this bring? These addresses would remain in the block chain anyway...

And finally we could try to use the oldest inputs which would allow the network to Stub off old blocks since the only useful information we can get from it is its hash which has been confirmed.

Can old transactions be really forgotten like this? I've seen people saying this around here before, but it sounds a bit dangerous to me. (deleting data is always a dangerous decision)
I mean, isn't it a problem at all to have a missing link in the chain? Suppose every miner does it, there would be no proof left that certain bitcoins are really linked to its generation block...

I'm not sure yet which one is best

Well, I think - I might be wrong - that bandwidth is a scarcer resource than disk space. So, to me, it sounds more reasonable trying to focus on reducing the bandwidth necessary to be a miner. So maybe minimizing transaction size is more interesting...
By the way, it will probably be on transaction size that fees will be charged anyway.

[Gavin Andresen]

(Edit: Hal's explanation fits. People must be sending Faucet coins to the Faucet.)

"people" is me-- when I tweak the Faucet's code I erase my IP address from its database and then have it send coins to itself as a sanity test.

And Hal's right, Bitcoin chooses transactions to spend, not specific outputs (which only matters for sends-to-self, where you own both outputs of a transaction).

[casascius]

Well,  there may be several optimization targets. One is what you described to minimize the number of inputs to reduce the transaction size. Another may be to use the smallest possible inputs which increases transaction size but also reduces the number of inputs we have to track (long term optimization).

I'm not sure I understood this "long term optimization". By smallest I believe you mean in BTC amount, right? The goal would be to spend smaller addresses quicker in order to have less addresses with money in it, is that it?
Besides shrinking people's wallets, what optimization could this bring? These addresses would remain in the block chain anyway...

I was thinking about this recently - this doesn't seem like such a bad idea.  It's not so much to shrink people's wallets, it's to shrink the block chain - or more specifically, to shrink the total number of bytes one must store in order to only have a record of unspent transactions.  It might also be a good idea to favor spending coins from transactions that are large (in bytes) so the sooner those transactions can be pruned.

Aggregating small inputs has an anonymity consequence: it publicly links the owner of all those small inputs, providing far more useful information to someone trying to follow coins on the chain.

And finally we could try to use the oldest inputs which would allow the network to Stub off old blocks since the only useful information we can get from it is its hash which has been confirmed.

Can old transactions be really forgotten like this? I've seen people saying this around here before, but it sounds a bit dangerous to me. (deleting data is always a dangerous decision)
I mean, isn't it a problem at all to have a missing link in the chain? Suppose every miner does it, there would be no proof left that certain bitcoins are really linked to its generation block...

I am not sure that old transactions could or should ever be truly forgotten by everybody, but forgotten by most would be fine - it would be a per-user choice.  When transaction pruning is properly implemented, the total size of downloading ALL transactions versus only unspent ones will diverge infinitely.  Users could choose between a minimal block chain, or a multi terabyte version under the pretense of "donating your disk space and bandwidth resources to the network" for the purpose of preserving all history.  A user could select whether they wanted full or pruned blocks and this preference would be sent via the P2P protocol.

I'm not sure yet which one is best

Well, I think - I might be wrong - that bandwidth is a scarcer resource than disk space. So, to me, it sounds more reasonable trying to focus on reducing the bandwidth necessary to be a miner. So maybe minimizing transaction size is more interesting...
By the way, it will probably be on transaction size that fees will be charged anyway.

By properly pruning blocks and taking actions to reduce size of past blocks, both can be reduced.  If blocks aren't pruned, they must continue to be passed around in full.  I would propose that it's a reasonable endeavor to focus on reducing the bandwidth of being a casual user, less so a miner.

Even so, being a miner requires no more bandwidth than being a non-miner.  Either you are running a client that listens for all current transaction activity and maintains a block chain, or you do not.  Mining should be equally possible with a pruned versus non-pruned block chain.

[Pieter Wuille]

And Hal's right, Bitcoin chooses transactions to spend, not specific outputs (which only matters for sends-to-self, where you own both outputs of a transaction).

This pull request should fix this issue: https://github.com/bitcoin/bitcoin/pull/116

[theymos]

The new "sendmulti" RPC command might cause this problem a lot, since services will not-too-rarely be paying twice (or more) to the same person at different addresses.

[JollyGreen]

And Hal's right, Bitcoin chooses transactions to spend, not specific outputs (which only matters for sends-to-self, where you own both outputs of a transaction).

This pull request should fix this issue: https://github.com/bitcoin/bitcoin/pull/116

This sounds like a good patch to implement, is there a next step to getting it commited into the root of bitcoin?  Is this pending code review?

[JollyGreen]

I built and ran sipa's code and was just testing it out with the testbox [mike] created,

here is the result of listtransactions after making a few sends thru the gui
{
    "" : 3725.00000000,
    "Test" : 10.00000000,
    "Test2" : 5.00000000,
    "Your Address" : 10.00000000
}

Next I transferred 3726.0 to "Your Address"
{
    "" : -1.00000000,
    "Test" : 10.00000000,
    "Test2" : 5.00000000,
    "Your Address" : 3736.00000000
}

Should a balance be able to be negative?

[theymos]

Should a balance be able to be negative?

That's normal. The blank account's balance goes negative when you send more BTC than is unallocated to accounts.