I stumbled across this when I was waiting for two transaction from the same sender, but to two different addresses which I used to keep both amounts separated for the sake of an overview. Let's say you do business with someone and work on two projects for that person. It still would be desireable to see that you got amount x for job 1 and amount y for job 2. Of course it doesn't make a difference balance-wise, but you can scroll back through your history and easily see which project earned you how much. It actually isn't confusing at all: I expect two transactions and the sender makes two transactions. But in the end it gets added up into one of both addresses.
It's kinda like shopping: you buy two items and pay the sum. But on the receipt, you still see how much each item cost (apples and oranges, I know). Of course you can go to the seller's website and search the prices, but it's simpler to just look at the receipt.
Topic: Incoming transactions are added? (Read 940 times)
I don't really understand your example anymore. Did you give Bob address X and Y? How is Bob sending you two outputs to two different addresses?
Yes, Bob was given both X and Y. See my edit for some example scenarios.For me what happened is that I used a separate address for each worker in my mining pool. I wanted to know how much each generated. But instead, the client's display merged all coins received from the pool, so I didn't know which is which (of course I can collect the info from blockexplorer, and it didn't matter that much to me, but again, I could have really cared about this and I could have wanted to do this conveniently without hunting addresses in BE. And again, there's no justification to merge).
I don't really understand your example anymore. Did you give Bob address X and Y? Why is Bob sending you two outputs to two different addresses?
If you gave X to Bob, and Y to Alice, and you got a transaction with two outputs, one to each address... the only reasonable explanation is that Bob and Alice are the same person, or are doing something very creative -- Bob and Alice would have to get together, and create a single joint transaction using inputs from both of their wallets, and sending to outputs both X and Y in the same transaction. That just doesn't happen, and the software has no incentive to try to distinguish this situation (if it were possible).
Or am I still misunderstanding?
If you gave X to Bob, and Y to Alice, and you got a transaction with two outputs, one to each address... the only reasonable explanation is that Bob and Alice are the same person, or are doing something very creative -- Bob and Alice would have to get together, and create a single joint transaction using inputs from both of their wallets, and sending to outputs both X and Y in the same transaction. That just doesn't happen, and the software has no incentive to try to distinguish this situation (if it were possible).
Or am I still misunderstanding?
In your example, this is really the same thing. It's just with multiple output addresses instead of input addresses.
In other words, it's not the same thing at all. Senders are identified by the output address, not the input address. If I tell Bob to pay me by sending to address X, I know that anything that I receive to X is from Bob. I don't care what the input address is, only the output address (and indeed, the client tells me the output address but not the input address). If the client represents a payment to address X as a payment to my other address Y that's misleading.True, there aren't many scenarios where this would happen. But for these scenarios we do want to know the true addresses, and there's absolutely no justification to merge them.
For me the scenario was mining pool rewards. Another imaginable scenario: Bob purchases products A and B from me, in amounts not agreed in advance but rather determined from the actual payment sent. I tell him to pay address X for product A and address Y for product B. If both payments are in the same block (I think it doesn't even have to be the same transaction), I don't know how much he paid for each. Also donations (send to X to support my project A, to Y to support B) and voting (X to vote A, Y to vote B - assuming one wants to vote for multiple items).
This is actually a feature, not a bug, for the sake of "let's dumb it down for the average user." If you look at it in block explorer, you'll see what you expect.
Let's look at a simpler example: basically every transaction that is executed by the client. You want to send someone 72 BTC. So your client combines 4 different inputs that add up to 85, constructs an output transaction with 72 BTC and 13 BTC change back to yourself (at a different address).
If what you suggest is a bug were fixed, the user would see 5 new transactions in their client... 4 transactions of arbitrary amounts (but adding up to 85) and one transaction in for 13. The user never authorized 5 different transactions of any of those amounts: he only issued one transaction for 72 BTC.
By accumulating the data in the transaction ledger to only show the net outcome of a transaction, the user sees what they expected: which is the total net debit to their wallet is 72 BTC. The alternative would be ridiculously confusing. It would even be annoying for users that understand it: they know that multiple addresses were used, but they only want to see the net, too.
In your example, this is really the same thing. It's just with multiple output addresses instead of input addresses.
Let's look at a simpler example: basically every transaction that is executed by the client. You want to send someone 72 BTC. So your client combines 4 different inputs that add up to 85, constructs an output transaction with 72 BTC and 13 BTC change back to yourself (at a different address).
If what you suggest is a bug were fixed, the user would see 5 new transactions in their client... 4 transactions of arbitrary amounts (but adding up to 85) and one transaction in for 13. The user never authorized 5 different transactions of any of those amounts: he only issued one transaction for 72 BTC.
By accumulating the data in the transaction ledger to only show the net outcome of a transaction, the user sees what they expected: which is the total net debit to their wallet is 72 BTC. The alternative would be ridiculously confusing. It would even be annoying for users that understand it: they know that multiple addresses were used, but they only want to see the net, too.
In your example, this is really the same thing. It's just with multiple output addresses instead of input addresses.
Looks like the same phenomenon I reported here. It's a bug if you ask me, but I didn't get taken seriously back then.
I just ran the following example in the testnet:
Bob has an address which holds 500BTC and he sends out a transaction to two recipient addresses (100BTC each), both of which belong to Alice. She however receives a single 200BTC transaction to the first address only and the second address isn't used.
Now, from what I know, the client sums up coins from multiple addresses to get the amount you want to send out, but shouldn't the recipient see the two transactions in his client?
Granted it's a very special case, but it's somewhat confusing, especially since the blockexplorer shows transactions to both addresses.
Bob has an address which holds 500BTC and he sends out a transaction to two recipient addresses (100BTC each), both of which belong to Alice. She however receives a single 200BTC transaction to the first address only and the second address isn't used.
Now, from what I know, the client sums up coins from multiple addresses to get the amount you want to send out, but shouldn't the recipient see the two transactions in his client?
Granted it's a very special case, but it's somewhat confusing, especially since the blockexplorer shows transactions to both addresses.
Jump to: