Returning BTC to the sender

[dscotese]

SatoshiDice tells players to verify that their wallets will accept bitcoin back into the same address from which it was sent because that's how SatoshiDice pays winners.  I would like to do this as well on a website I'm working on but I can't find information about how (or whether) the JSON-RPC API can be used to identify the address to which btc should be returned.

Is there a "return-to-sender" method in the public domain that can be done with the JSON-RPC API?  If not, is there one at all?

Thanks!

[CIYAM]

This has been covered before but I can't find the topic now so take at look at a tx such as this:

http://blockchain.info/tx/b207c397de2b48305dcad413115163726ddb98512d5e89e179c88fd210b0145e?show_adv=true

now if you scroll down the bottom you'll see the scripts and outputs.

Basically what you want to do is "decoderawtransaction" to work out the input address(es) and then construct a raw tx with two outputs one for your "earnings" and the other for their "refund" (just send to the first input address I guess).

You can get a clear idea of how the raw tx looks with brainwallet.org (click on the Transactions tab) *but* do not use this site *online* with any of your own private keys.

Although not built for this purpose (it is for offline signing of raw tx's) something like this might be of help also: http://ciyam.org/rawtx_helper.html (understand this page doesn't *do* anything other than format raw tx commands but again don't use it online with any real data from your hot wallet).

[DannyHamilton]

SatoshiDice tells players to verify that their wallets will accept bitcoin back into the same address from which it was sent because that's how SatoshiDice pays winners.  I would like to do this as well on a website I'm working on but I can't find information about how (or whether) the JSON-RPC API can be used to identify the address to which btc should be returned.

Is there a "return-to-sender" method in the public domain that can be done with the JSON-RPC API?  If not, is there one at all?

Thanks!

Wouldn't it be a better practice to have users provide you with an address for you to send payments?

[CIYAM]

Wouldn't it be a better practice to have users provide you with an address for you to send payments?

Agreed - but I think it is the "simplicity" (provided you are using the right client) of Satoshi dice that appeals (to those that like to gamble - have never used it myself).

[dscotese]

Wouldn't it be a better practice to have users provide you with an address for you to send payments?

I don't want the website to have to prove that the person to whom the bitcoin is sent is the same person to whom it was owed.  I believe many payers will never tell anyone who they are, often only because that is an extra hassle (and only very rarely because they have truly bad reasons to remain anonymous).

Basically what you want to do is "decoderawtransaction" to work out the input address(es)...

Here is what I did:
1. Get a txid from one of my wallet transactions.
2. getrawtransaction (the txid).  This gave me a hex string.
3. decoderawtransaction (the hex string).  This gives me a single vin with a txid and a vout with two objects that each contained a scriptPubKey (my address was in one of them, and I assume the "change" address for the payer was in the other).  I recorded the sum of the values of these two objects as PayerOriginalBalance.
4. getrawtransaction (the vin's txid).  This gave me a large hex string.
5. decoderawtransaction (the large hex string).  This gave me a vin that I am ignoring - it's how the payer got the bitcoin he sent me, right?  It also gave me a vout that held two objects, each with an address.  Only one of the objects had a value greater or equal to what I received (in fact, it was exactly 0.0005 more than PayerOriginalBalance - the Tx Fee, I assume).  I assume that when there are multiple objects in the vout (usually two, the source and an address for change), the payer controls all of them, so any of them is suitable for the refund.  That's why you wrote this, right?

(just send to the first input address I guess)

I've been trying to imagine a vout containing objects with addresses that the payer can't use, and I think the only way for that to happen is for the payer to create it, but even then, the ability to create it requires that he have the private keys for all the addresses, right?

[Gavin Andresen]

I've been trying to imagine a vout containing objects with addresses that the payer can't use, and I think the only way for that to happen is for the payer to create it, but even then, the ability to create it requires that he have the private keys for all the addresses, right?

No. It is perfectly possible for multiple people to provide inputs to a transaction, each signing their input but without knowledge of the other people's keys.

That is extremely rare now, but that is exactly what you would do to implement a peer-to-peer coin-mixing service, which I suspect may be a very popular way of paying for things since it increases your privacy significantly.

[kjj]

As I've mentioned in a few dozen other threads, there is no "return to sender" in bitcoin.  There is no sender even.  Transactions redeem other transactions, and they can mix in funny ways.

If you need return functionality, you have three choices.

1.  Collect that information before you provide the payment address so that you can track them together.
2.  Wait for the payment message system.  This is basically a special case of option 1.
3.  Make assumptions about the system that are not true, in general.  You can get away with this most of the time, but sooner or later, you'll get caught.

[dscotese]

3.  Make assumptions about the system that are not true, in general.  You can get away with this most of the time, but sooner or later, you'll get caught.

Has SatoshiDice gotten caught?  Does their warning ("IMPORTANT: Only use wallets that allow you to receive Bitcoin from the same address you sent from. If you're not sure, test with .001 Bitcoins. If you get nothing back, then your wallet is not compatible.") protect them from *your* expectations?  I would include that warning or something similar. 

I suppose the other option is to return bitcoins proportionally to the addresses listed in the vout of the supplying transaction.

blockchain.info identifies the source address of the transaction I used to perform the steps I listed above.  It's obvious to me now that I've done the math, but how does blockchain.info know what the source address of a single-input transaction is?

[kjj]

3.  Make assumptions about the system that are not true, in general.  You can get away with this most of the time, but sooner or later, you'll get caught.

Has SatoshiDice gotten caught?  Does their warning ("IMPORTANT: Only use wallets that allow you to receive Bitcoin from the same address you sent from. If you're not sure, test with .001 Bitcoins. If you get nothing back, then your wallet is not compatible.") protect them from *your* expectations?  I would include that warning or something similar. 

I suppose the other option is to return bitcoins proportionally to the addresses listed in the vout of the supplying transaction.

blockchain.info identifies the source address of the transaction I used to perform the steps I listed above.  It's obvious to me now that I've done the math, but how does blockchain.info know what the source address of a single-input transaction is?

Except that it doesn't identify the source address, because, and this is very important, there is no such concept of a source address in bitcoin.  The only concept that applies is that of a source transaction.  Hell, there really aren't even addresses if you want to get deep into it.  The destinations of transactions are scripts.  You and I (and the software) use things we call addresses to help generate those scripts, but they don't really exist.

This may seem like I'm splitting hairs, particularly when virtually all transaction fit a particular mold and directly embed that abstraction that we use for our convenience.  But if you insist on thinking that transactions come from addresses, you are reading your map, not the territory, and you will run into problems when you get to the place where your map is wrong.

SatoshiDice probably gets caught every day.  We have no way of knowing how many people find the address and send coins from shared wallets.  In the future, when multiparty wallets and mixers get more common, we'll have no way of knowing how many people will make the same mistake with them.  How could we know, unless someone wants to make a public issue of it?  From our point of view, and from SatoshiDice's point of view, the transaction came in, and then went out.  It all looks the same to us.

They can get away with it because they don't care.  They don't care if they send your winnings into limbo.  They don't care if they piss off one gambler out of millions.

But most people can't get away with that.  They are in businesses that must care about customer service.  And if you think that you don't care about customer service, then you are probably hoping to make a clone, in which case, you have much bigger problems.

[dooglus]

Here is what I did:
1. Get a txid from one of my wallet transactions.
2. getrawtransaction (the txid).  This gave me a hex string.
3. decoderawtransaction (the hex string).  This gives me a single vin with a txid and a vout with two objects that each contained a scriptPubKey (my address was in one of them, and I assume the "change" address for the payer was in the other).  I recorded the sum of the values of these two objects as PayerOriginalBalance.
4. getrawtransaction (the vin's txid).  This gave me a large hex string.
5. decoderawtransaction (the large hex string).  This gave me a vin that I am ignoring - it's how the payer got the bitcoin he sent me, right?  It also gave me a vout that held two objects, each with an address.  Only one of the objects had a value greater or equal to what I received (in fact, it was exactly 0.0005 more than PayerOriginalBalance - the Tx Fee, I assume).  I assume that when there are multiple objects in the vout (usually two, the source and an address for change), the payer controls all of them, so any of them is suitable for the refund.  That's why you wrote this, right?

Step 3 can give you multiple inputs (vin) but each has both a txid and a vout.  The vout of each txid tells you which of the multiple outputs you see in step 5 to look at.

It isn't safe at all to assume that the payer controls anything other than the output he sent you.  He could be spending his earnings from a mining pool.  Those payments typically have many outputs, one to each participant in the pool.

Here's some Python code to get the return address (the address of the first input) given a txid from your wallet:

Code:

#!/usr/bin/env python
import json, posix, sys

bitcoind = "~/Bin/bitcoind"

def raw(tx):
    return json.load(posix.popen("%s decoderawtransaction $(%s getrawtransaction %s)" % (bitcoind, bitcoind, tx)))

first_input = raw(sys.argv[1])['vin'][0]

print raw(first_input['txid'])['vout'][first_input['vout']]['scriptPubKey']['addresses'][0]

and an example of its use:

Code:

chris@chris:~/Programs/BitcoinArmory/extras$ ~/Source/Python/return_address.py a3730a36bdd5c9f74c65e5f56f25767291e2bd2cf744876a3c5197db3a5edf45
17org1nf9JJNfEQQuBir8VSNL16cfudo8t

The transaction I used has multiple inputs and outputs: