0
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?
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.
1
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.)
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 – 2017-07-27T15:05:54.660
You're fine if you ask the user for a specific return address. That's what ShapeShift does. – David Schwartz – 2017-07-27T19:22:43.017
@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 – 2019-03-18T21:16:18.280
@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 – 2019-03-18T23:04:18.110
@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 – 2019-03-21T18:30:06.940
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 – 2019-03-21T18:35:14.080
@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 – 2019-03-21T19:13:00.937
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 :-)
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 – 2017-07-27T08:14:29.203
this is, why we need more PWKUs (Pieter Wuille Knowledge Units) in the blockchain field :-) – pebwindkraft – 2017-07-29T09:46:01.143
In my original question, would I have to implement some sort of cryptography? I didn't think I would need to. – Uzinium – 2017-07-27T15:04:08.907
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 – 2017-07-28T06:23:20.857