<p>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:</p>

<ul>
<li>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)</li>
<li>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)</li>
<li>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</li>
<li>Multiple inputs, multiple outputs - probably should work as the previous case</li>
</ul>

<p>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.</p>

CC BY-SA 3.0
2011-12-31T14:15:02.577Z
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
CC BY-SA 3.0
2011-12-31T15:51:20.180Z
@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
CC BY-SA 3.0
2011-12-31T16:08:11.110Z
OK, so I'll assume the tx has 1-2 outputs, and pick one of the inputs arbitrarily as my payback address.
ripper234
CC BY-SA 3.0
2011-12-31T13:54:04.320Z
2011-12-31T13:54:04.320Z
ThePiachu
<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2012-01-01T06:50:00.313Z
Hmm. So I have to ask the user to provide a return address? This sucks :(
ripper234
CC BY-SA 3.0
2012-01-01T07:57:30.190Z
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
CC BY-SA 3.0
2011-12-31T19:24:46.997Z
2011-12-31T19:24:46.997Z
Meni Rosenfeld
<p>I want to write code that accepts a transaction, and afterwards "pays back" some amount to the origin of the transaction.</p>

<p>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?</p>

<p>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.</p>

<development><protocol>
In order to "pay someone back", must I ask them for a return address?
ripper234
# In order to "pay someone back", must I ask them for a return address?

(Asked by: username_0 on 2011-12-31)

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.

**Tags:** development, protocol


---

## 2 answers

### Answer by username_2 on 2011-12-31. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_0**: Hmm. So I have to ask the user to provide a return address? This sucks :(  
> **username_2**: 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.  

---

### Answer by username_1 on 2011-12-31. Score: 1

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.

> **Comments:**
> **username_0**: 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?  
> **username_1**: @username_0 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.  
> **username_0**: OK, so I'll assume the tx has 1-2 outputs, and pick one of the inputs arbitrarily as my payback address.  

---

