<p>You should ask for a return address. Bitcoin transactions don't contain any "from address", it only references another (previous) transaction's output. An output can be a P2PKH (Pay to public key hash), but it can just as well be P2SH (Pay to script hash) and some other may be implemented in the future.</p>

<p>There's also a large possibility of getting a transaction referencing many previous outputs, as happens when someone paying you 1 BTC received many smaller transaction previously.</p>

<p>It would also be unintuitive to your users, as it's bitcoin best practice not to care about where the bitcoins come from and instead to generate a new address for every transaction received.</p>

<p>On top of that, you shouldn't implement any cryptography by yourself if you're not already a top-level expert, there are simply too many things that can go wrong. I would recommend using a proper API.</p>

CC BY-SA 3.0
2017-07-27T15:04:08.907Z
In my original question, would I have to implement some sort of cryptography? I didn't think I would need to.
Uzinium
CC BY-SA 3.0
2017-07-28T06:23:20.857Z
You would have to create a bitcoin transaction, and this is cryptography. You are not implementing the calculations, but you are working with key management (chosing which address to send to).
Hubert Jasieniecki
CC BY-SA 3.0
2017-07-27T06:09:17.093Z
2017-07-27T06:09:17.093Z
Hubert Jasieniecki
<p>For the love of all that is holy, do not do this. Consider:</p>

<p>Alice wants to send you 1 bitcoin. She asks her wallet provider to send you 1 bitcoin. Her wallet provider sends you the bitcoins it got from Bob when he deposited into his wallet.</p>

<p>You look at the transaction and see that the coins came from Bob's deposit address. So you send coins back to that address. Alice's wallet provider sees coins received to Bob's deposit address and credits Bob.</p>

<p>Bob wonders why he received some bitcoins from a random stranger, but since he has no idea who you are and no way to contact you, he just keeps them. Heck, maybe it's an address he made public as a tip jar and he has no reason not to think it's a tip.</p>

<p>Alice might eventually wonder why she didn't get her bitcoins. If she contacts you, you'll give her the transaction ID. She'll think, "Hmm, that's not my address. But it must belong to my wallet provider. So they must have the bitcoins. When I explain to them that they're mine, they should credit them to me."</p>

<p>And now we have a massive mess where everyone is blaming everyone else and Alice thinks her wallet provider stole from her and you think it wasn't your fault. But you're wrong.</p>

<p>Please do not do this. It does not make any sense. (The story above is real. Only the names have been changed to protect the innocent ... and the guilty.)</p>

CC BY-SA 3.0
2017-07-27T15:05:54.660Z
So is there no way to do what I'm trying to do? Even if I ask for a specific return address from the user?
Uzinium
CC BY-SA 3.0
2017-07-27T19:22:43.017Z
You're fine if you ask the user for a specific return address. That's what ShapeShift does.
David Schwartz
CC BY-SA 4.0
2019-03-18T21:16:18.280Z
@DavidSchwartz You say "It does not make any sense", but in what way does it not make sense?  Every party is making assumptions, and I say the wallet provider spent money it shouldn't of... a very obvious assumption for every party involved except the wallet provider, so what makes the wallet providers (i.m.o. invalid) assumptions more valid than everyone elses assumptions? Why should the wallet provider use a public-key encryption system as if it were a symmetric key system (e.g. violating the trusted private ownership of private keys they were trusted to administer) and not be held at fault?
user3338098
CC BY-SA 4.0
2019-03-18T23:04:18.110Z
@user3338098 I'm just explaining that this does not work because the bitcoin system was never designed to make this work. It doesn't make sense because it doesn't actually return the bitcoins to the right party and because there is no reason to expect it to do so. There's no violation of the trusted private ownership of private keys -- the provider owns the private keys and the public keys are public.
David Schwartz
CC BY-SA 4.0
2019-03-21T18:30:06.940Z
@DavidSchwartz `there is no reason to expect it to do so` why? bitcoin core doesn't provide a statement of expected behavior or semantics they only provide the reference code base.  The original white-paper states `coins made from digital signatures, which provides strong control of ownership` not control that is transferred from user to user... it also states `a new key pair should be used` it says **should** it does not say **must**... Without a centralized authority to state which point of view is valid and canonical, they must both be valid.  So why is my point of view invalid?
user3338098
CC BY-SA 4.0
2019-03-21T18:35:14.080Z
It's like saying that the `control of ownership` is in the web-providers hands and therefore there are no guarantees who will receive the money, the web-provider could steal all the money for themselves, so therefore using ANY web-provider based payment address should not be expected to send money to the user you expect it to...
user3338098
CC BY-SA 4.0
2019-03-21T19:13:00.937Z
@user3338098 My answer explains how your point of view leads to incorrect conclusions. Your statement above about web providers is right and that's why we don't randomly send money to places web providers tell us to absent evidence that a particular recipient specifically asked us to send money to a location we obtained from a particular web provider. That evidence is specifically what we don't have in the case of bitcoin.
David Schwartz
CC BY-SA 4.0
2021-07-05T20:12:15.327Z
@DavidSchwartz `That evidence is specifically what we don't have`, then what is "404371705fa9bd789a2fcd52d2c580b65d35549d" in `OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG` in the `scriptPubKey`, and why does it require a private key to sign it in the `scriptSig`.  *Cryptographically signed* evidence.
user3338098
CC BY-SA 4.0
2021-07-05T20:16:48.563Z
@DavidSchwartz `Your statement above about web providers is right`, but I was making an absurd argument (`the web-provider could steal all the money for themselves [...] should not be expected to send money to the user you expect it to...`) whose only conclusion would be that no one should ever use a web provider (with the exception of web-provider based money laundering/masochistic donations).  This would contradict the very premise for web-provider based wallets.
user3338098
CC BY-SA 4.0
2021-07-05T20:30:12.533Z
@DavidSchwartz lets make this simple, bob does not deposit bitcoins, but rather deposits cash into his account, and the web-provider, instead of transferring that amount to his bitcoin address, as expected (I.M.O.), will instead allocate his funds from a "pooled community bitcoin address", and that is what Alice and Bob both end up spending from. This violates the principle of ownership and has not yet been discussed in our conversation, but ***if*** this were the case, then I would agree there was no evidence, but I would also say that the web-provider was in the wrong I.M.O..
user3338098
CC BY-SA 4.0
2021-07-07T17:02:28.670Z
@user3338098 I don't understand what "principle of ownership" you think it violates. If I owe you money, it's quite natural for me to direct someone who owes me money to pay that money to you. It's perfectly normal for you not to get the money directly from the person who owed you the money. This is the reason financial intermediaries exist, and most people who use bitcoin do so through intermediaries because doing self-custody right is hard.
David Schwartz
CC BY-SA 4.0
2023-02-06T16:58:22.977Z
@DavidSchwartz `I don't understand what "principle of ownership" you think it violates.`  As stated previously, the original white-paper states `coins made from digital signatures, which provides strong control of ownership...`.  or with more direct language:  `signature` = `ownership`.  In bitcoin if you do not have the private key then it is *not your money*.
user3338098
CC BY-SA 4.0
2023-02-06T17:19:04.987Z
@DavidSchwartz If I perform an ACH with my bank as the financial intermediary and the receiving bank declined the transaction and my funds went to someone else's account, that is not my problem, that is not the receiving banks problem, it is *my* banks problem.  The intermediary is the one in the wrong. If someone uses an E.B.T. S.N.A.P. benefit card for buying their groceries, should they get a refund in cash, of course not, that would be FRAUD, it is not their money. If someone makes a purchase with a credit card, should they get a refund in cash, of course not, it is not their money.
user3338098
CC BY-SA 4.0
2023-02-06T20:28:38.267Z
@user3338098 As I said, it is quite normal for Bob to pay Alice by having Charlie send some of Charlie's money to Alice on Bob's behalf. There is no rule that says Bob has to have ownership of the money he uses to pay Charlie. It is absolutely routine to use someone else's money to settle a debt if that someone else owes you money. 1/2
David Schwartz
CC BY-SA 4.0
2023-02-06T20:29:24.970Z
@user3338098 It is absolutely a mistake to assume that because Bob once paid Alice with Charlie's money, Alice can send money to Charlie and expect Charlie to give it to Bob. Alice has no idea what arrangements Bob might have used to pay her and she should not make assumptions about how that arrangement extends beyond the transaction that pays her. 2/2
David Schwartz
CC BY-SA 3.0
2017-07-27T09:23:43.233Z
2017-07-27T09:23:43.233Z
David Schwartz
<blockquote>
  <p>How would you do this?</p>
</blockquote>

<p>I would provide my more or less "public" address. Then people could send Satoshis to this address. Once a transaction with Satoshis is confirmed, I would analyze the transaction, cause it contains the scriptsig and pubkey (from which we can derive the sending address). So I would store this, and when time comes in, send back to this adress. Problem here: it reduces privacy. It is not recommended to re-use addresses.</p>

<blockquote>
  <p>Does bitcoin have the ability to send and receive coins through the
  same address</p>
</blockquote>

<p>yes, you can setup/program your transaction in a way, that addresses are re-used. Need to have sufficient skills though :-)</p>

<blockquote>
  <p>or would I have to ask for a return address and somehow link the sent
  amount address to the return address?</p>
</blockquote>

<p>imho, this is the better and desired way, cause it keeps privacy. Also you don't need to link amount to address - this can become insecure (two people sending same amount - how to differentiate?). As before, the transaction can be reviewed, you can extract sig and pubkey, and link orig pub key (and it's address) to new address.<br>
On transactions and it's contents: <a href="https://bitcoin.org/en/developer-reference#raw-transaction-format" rel="nofollow noreferrer">https://bitcoin.org/en/developer-reference#raw-transaction-format</a>
and also very helpful: <a href="http://chimera.labs.oreilly.com/books/1234000001802/ch02.html#_bitcoin_transactions" rel="nofollow noreferrer">http://chimera.labs.oreilly.com/books/1234000001802/ch02.html#_bitcoin_transactions</a>
(and probably a million others :-)</p>

CC BY-SA 3.0
2017-07-27T08:14:29.203Z
Privacy is not the only issue. What is the sending transaction is a coinjoin? You're risking sending back to the wrong person. And even if not, you shouldn't expect the sender software to expect a payment to an address it may never have given out explicitly as payment address (it could have been change even, not knowing who to credit it to).
Pieter Wuille
CC BY-SA 3.0
2017-07-29T09:46:01.143Z
this is, why we need more PWKUs (Pieter Wuille Knowledge Units) in the blockchain field :-)
pebwindkraft
CC BY-SA 3.0
2017-07-27T08:09:14.907Z
2017-07-27T08:09:14.907Z
pebwindkraft
<p>I am trying to write a program to receive bitcoin, and then after some time, return the same amount of bitcoin to the same address.</p>

<p>How would you do this? Does bitcoin have the ability to send and receive coins through the same address, or would I have to ask for a return address and somehow link the sent amount address to the return address?</p>

<development><protocol>
How do you return a specific amount of bitcoin to an address?
Uzinium
# How do you return a specific amount of bitcoin to an address?

(Asked by: username_0 on 2017-07-27)

I am trying to write a program to receive bitcoin, and then after some time, return the same amount of bitcoin to the same address.

How would you do this? Does bitcoin have the ability to send and receive coins through the same address, or would I have to ask for a return address and somehow link the sent amount address to the return address?

**Tags:** development, protocol


---

## 3 answers

### Answer by username_1 on 2017-07-27. Score: 2

You should ask for a return address. Bitcoin transactions don't contain any "from address", it only references another (previous) transaction's output. An output can be a P2PKH (Pay to public key hash), but it can just as well be P2SH (Pay to script hash) and some other may be implemented in the future.

There's also a large possibility of getting a transaction referencing many previous outputs, as happens when someone paying you 1 BTC received many smaller transaction previously.

It would also be unintuitive to your users, as it's bitcoin best practice not to care about where the bitcoins come from and instead to generate a new address for every transaction received.

On top of that, you shouldn't implement any cryptography by yourself if you're not already a top-level expert, there are simply too many things that can go wrong. I would recommend using a proper API.

> **Comments:**
> **username_0**: In my original question, would I have to implement some sort of cryptography? I didn't think I would need to.  
> **username_1**: You would have to create a bitcoin transaction, and this is cryptography. You are not implementing the calculations, but you are working with key management (chosing which address to send to).  

---

### Answer by username_2 on 2017-07-27. Score: 2

For the love of all that is holy, do not do this. Consider:

Alice wants to send you 1 bitcoin. She asks her wallet provider to send you 1 bitcoin. Her wallet provider sends you the bitcoins it got from Bob when he deposited into his wallet.

You look at the transaction and see that the coins came from Bob's deposit address. So you send coins back to that address. Alice's wallet provider sees coins received to Bob's deposit address and credits Bob.

Bob wonders why he received some bitcoins from a random stranger, but since he has no idea who you are and no way to contact you, he just keeps them. Heck, maybe it's an address he made public as a tip jar and he has no reason not to think it's a tip.

Alice might eventually wonder why she didn't get her bitcoins. If she contacts you, you'll give her the transaction ID. She'll think, "Hmm, that's not my address. But it must belong to my wallet provider. So they must have the bitcoins. When I explain to them that they're mine, they should credit them to me."

And now we have a massive mess where everyone is blaming everyone else and Alice thinks her wallet provider stole from her and you think it wasn't your fault. But you're wrong.

Please do not do this. It does not make any sense. (The story above is real. Only the names have been changed to protect the innocent ... and the guilty.)

> **Comments:**
> **username_0**: So is there no way to do what I'm trying to do? Even if I ask for a specific return address from the user?  
> **username_2**: You're fine if you ask the user for a specific return address. That's what ShapeShift does.  
> **username_3**: @username_2 You say "It does not make any sense", but in what way does it not make sense?  Every party is making assumptions, and I say the wallet provider spent money it shouldn't of... a very obvious assumption for every party involved except the wallet provider, so what makes the wallet providers (i.m.o. invalid) assumptions more valid than everyone elses assumptions? Why should the wallet provider use a public-key encryption system as if it were a symmetric key system (e.g. violating the trusted private ownership of private keys they were trusted to administer) and not be held at fault?  
> **username_2**: @username_3 I'm just explaining that this does not work because the bitcoin system was never designed to make this work. It doesn't make sense because it doesn't actually return the bitcoins to the right party and because there is no reason to expect it to do so. There's no violation of the trusted private ownership of private keys -- the provider owns the private keys and the public keys are public.  
> **username_3**: @username_2 `there is no reason to expect it to do so` why? bitcoin core doesn't provide a statement of expected behavior or semantics they only provide the reference code base.  The original white-paper states `coins made from digital signatures, which provides strong control of ownership` not control that is transferred from user to user... it also states `a new key pair should be used` it says **should** it does not say **must**... Without a centralized authority to state which point of view is valid and canonical, they must both be valid.  So why is my point of view invalid?  
> **username_3**: It's like saying that the `control of ownership` is in the web-providers hands and therefore there are no guarantees who will receive the money, the web-provider could steal all the money for themselves, so therefore using ANY web-provider based payment address should not be expected to send money to the user you expect it to...  
> **username_2**: @username_3 My answer explains how your point of view leads to incorrect conclusions. Your statement above about web providers is right and that's why we don't randomly send money to places web providers tell us to absent evidence that a particular recipient specifically asked us to send money to a location we obtained from a particular web provider. That evidence is specifically what we don't have in the case of bitcoin.  
> **username_3**: @username_2 `That evidence is specifically what we don't have`, then what is "404371705fa9bd789a2fcd52d2c580b65d35549d" in `OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG` in the `scriptPubKey`, and why does it require a private key to sign it in the `scriptSig`.  *Cryptographically signed* evidence.  
> **username_3**: @username_2 `Your statement above about web providers is right`, but I was making an absurd argument (`the web-provider could steal all the money for themselves [...] should not be expected to send money to the user you expect it to...`) whose only conclusion would be that no one should ever use a web provider (with the exception of web-provider based money laundering/masochistic donations).  This would contradict the very premise for web-provider based wallets.  
> **username_3**: @username_2 lets make this simple, bob does not deposit bitcoins, but rather deposits cash into his account, and the web-provider, instead of transferring that amount to his bitcoin address, as expected (I.M.O.), will instead allocate his funds from a "pooled community bitcoin address", and that is what Alice and Bob both end up spending from. This violates the principle of ownership and has not yet been discussed in our conversation, but ***if*** this were the case, then I would agree there was no evidence, but I would also say that the web-provider was in the wrong I.M.O..  
> **username_2**: @username_3 I don't understand what "principle of ownership" you think it violates. If I owe you money, it's quite natural for me to direct someone who owes me money to pay that money to you. It's perfectly normal for you not to get the money directly from the person who owed you the money. This is the reason financial intermediaries exist, and most people who use bitcoin do so through intermediaries because doing self-custody right is hard.  
> **username_3**: @username_2 `I don't understand what "principle of ownership" you think it violates.`  As stated previously, the original white-paper states `coins made from digital signatures, which provides strong control of ownership...`.  or with more direct language:  `signature` = `ownership`.  In bitcoin if you do not have the private key then it is *not your money*.  
> **username_3**: @username_2 If I perform an ACH with my bank as the financial intermediary and the receiving bank declined the transaction and my funds went to someone else's account, that is not my problem, that is not the receiving banks problem, it is *my* banks problem.  The intermediary is the one in the wrong. If someone uses an E.B.T. S.N.A.P. benefit card for buying their groceries, should they get a refund in cash, of course not, that would be FRAUD, it is not their money. If someone makes a purchase with a credit card, should they get a refund in cash, of course not, it is not their money.  
> **username_2**: @username_3 As I said, it is quite normal for Bob to pay Alice by having Charlie send some of Charlie's money to Alice on Bob's behalf. There is no rule that says Bob has to have ownership of the money he uses to pay Charlie. It is absolutely routine to use someone else's money to settle a debt if that someone else owes you money. 1/2  
> **username_2**: @username_3 It is absolutely a mistake to assume that because Bob once paid Alice with Charlie's money, Alice can send money to Charlie and expect Charlie to give it to Bob. Alice has no idea what arrangements Bob might have used to pay her and she should not make assumptions about how that arrangement extends beyond the transaction that pays her. 2/2  

---

### Answer by username_4 on 2017-07-27. Score: 0

> How would you do this?

I would provide my more or less "public" address. Then people could send Satoshis to this address. Once a transaction with Satoshis is confirmed, I would analyze the transaction, cause it contains the scriptsig and pubkey (from which we can derive the sending address). So I would store this, and when time comes in, send back to this adress. Problem here: it reduces privacy. It is not recommended to re-use addresses.

> Does bitcoin have the ability to send and receive coins through the
> same address

yes, you can setup/program your transaction in a way, that addresses are re-used. Need to have sufficient skills though :-)

> or would I have to ask for a return address and somehow link the sent
> amount address to the return address?

imho, this is the better and desired way, cause it keeps privacy. Also you don't need to link amount to address - this can become insecure (two people sending same amount - how to differentiate?). As before, the transaction can be reviewed, you can extract sig and pubkey, and link orig pub key (and it's address) to new address.  
On transactions and it's contents: <https://bitcoin.org/en/developer-reference#raw-transaction-format>
and also very helpful: <http://chimera.labs.oreilly.com/books/1234000001802/ch02.html#_bitcoin_transactions>
(and probably a million others :-)

> **Comments:**
> **username_5**: Privacy is not the only issue. What is the sending transaction is a coinjoin? You're risking sending back to the wrong person. And even if not, you shouldn't expect the sender software to expect a payment to an address it may never have given out explicitly as payment address (it could have been change even, not knowing who to credit it to).  
> **username_4**: this is, why we need more PWKUs (username_5 username_5 Knowledge Units) in the blockchain field :-)  

---

