In order to "pay someone back", must I ask them for a return address?

I want to write code that accepts a transaction, and afterwards "pays back" some amount to the origin of the transaction.

Assume users will be using the standard client. Will transactions have a single input, or must I handle the situation where a transaction have multiple inputs?

Can I just choose one of these inputs and pay back to that input? I want to avoid having to request users from entering a payout Bitcoin address - it's so much neater to just pay back to the same address they used.

ripper234

Posted 2011-12-31T13:06:34.123

Reputation: 25 192

Answers

Assuming that the user uses the standard client, or in fact any client, is a very strong assumption. If the user is using an eWallet service such as Instawallet, in all likelihood the user will not get the funds back, they will be held by the operator and possibly credited to one of his other clients.

Even if the input addresses are controlled in some way by the user, paying back to one of them can cause confusion regarding the payment's source - it will look as if the payment was for whatever the address was originally associated with. If there is a change address controlled by the user, it is associated uniquely with the payment to you so the information exists to identify it, though the client may not display it properly.

Meni Rosenfeld

Posted 2011-12-31T13:06:34.123

Reputation: 18 542

Hmm. So I have to ask the user to provide a return address? This sucks :( – ripper234 – 2012-01-01T06:50:00.313

Well, that depends. You could make an optional return address field, and clarify that if the user is not using the default client (or knows exactly what he's doing) he should fill this. It would be a good idea for eWallet providers to associate change addresses with the originating client, and in an ideal future where it is reasonable to expect eWallets to do this, it's safe to send to the change address. Also eWallets could offer the option to send a payment by routing it through an address associated with the client first. – Meni Rosenfeld – 2012-01-01T07:57:30.190

As any user can easily receive Bitcoins with multiple addresses, the transactions they send can have multiple inputs. There are a couple cases you should consider:

Single input, single output - easy case, send coins back to the input (unless some prankster mines coins onto your address, then you might as well keep them instead of sending them to some invalid address)
Any number of inputs, two outputs - the second output is probably where the user has sent its remaining coins, you might as well send them there (although you should explain it to the users first)
Multiple inputs, single output - you probably should provide the users with two functionalities - either sending coins to the first input, or sending the same amount of coins got from each input into each of them
Multiple inputs, multiple outputs - probably should work as the previous case

All in all, you should provide users with different functionalities, probably each using a different address for their transactions and see which are used more often.

ThePiachu

Posted 2011-12-31T13:06:34.123

Reputation: 41 594

Most users won't know anything about the kind of transaction they're generating. I don't want to complicate their lives. Will the outputs always be either 1 or 2? When will I get a tx with more than 2 outputs, from a legitimate user? – ripper234 – 2011-12-31T14:15:02.577

@ripper234 You can make the more complicated options less accessible, for example by putting them in "advanced options". From what I understand, the outputs will usually be 1 or 2 for the standard client, but someone might be using a non-standard client that allows one to send coins to multiple addresses at once. For now, I think those only appear in exchanges and mining pools, which probably won't be used to send you coins. – ThePiachu – 2011-12-31T15:51:20.180

OK, so I'll assume the tx has 1-2 outputs, and pick one of the inputs arbitrarily as my payback address. – ripper234 – 2011-12-31T16:08:11.110