how to get the "from address" from the bitcoin server client.

[jaminunit]

Hi yall,

So I'm creating a little game for fun and want to automatically send winnings back to the address that funded the game.
I see that http://bitbet.us/ did this. You can send them a bitcoin and they will send you any winnings back to the address it came from.

I have looked all through https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list but can't seem to find the function that does that.

[1715104016]

1715104016

[1715104016]

1715104016

[1715104016]

1715104016

[1715104016]

1715104016

[Come-from-Beyond]

Hi yall,

So I'm creating a little game for fun and want to automatically send winnings back to the address that funded the game.
I see that http://bitbet.us/ did this. You can send them a bitcoin and they will send you any winnings back to the address it came from.

I have looked all through https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list but can't seem to find the function that does that.

Try get txid and then analyze this transaction.

[jaminunit]

Thanks Come-from-Beyond
Hmmm this only seems to get me the receiving address

[jaminunit]

Oh ok the address is hashed.

Any tips on how to  unhash it

[Come-from-Beyond]

Oh ok the address is hashed.

Any tips on how to  unhash it

Can't help here. I used to use blockchain.info API - http://blockchain.info/address/660d4ef3a743e3e696ad990364e555c271ad504b?format=json

[kjj]

The bitcoin system has no such concept of a "from address", as has been explained in hundreds of threads.

[jaminunit]

Oh ok,
So does satoshi dice use the blockchain.ino api?

[jaminunit]

Ok after a heap of dry reading I think I'm going to have to change the way I track incoming and outgoing addresses and funding.

[bukaj]

Ok after a heap of dry reading I think I'm going to have to change the way I track incoming and outgoing addresses and funding.

What was your idea and why you think it is wrong? I'm asking, because I'm working on accepting coins myself.

[kjj]

The short version is that coins don't "come from" anywhere.  If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet.  But when they came to your wallet, they didn't come from that place.

And that is for simple transactions, it can get worse.

[bukaj]

I get it. Thank you.

[niko]

The short version is that coins don't "come from" anywhere.  If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet.  But when they came to your wallet, they didn't come from that place.

And that is for simple transactions, it can get worse.

Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work.

[kjj]

The short version is that coins don't "come from" anywhere.  If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet.  But when they came to your wallet, they didn't come from that place.

And that is for simple transactions, it can get worse.

Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work.

I think you are taking some metaphors too literally.

[niko]

The short version is that coins don't "come from" anywhere.  If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet.  But when they came to your wallet, they didn't come from that place.

And that is for simple transactions, it can get worse.

Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work.

I think you are taking some metaphors too literally.

I think there such thing as "from" address(es), and we can see them for any given transaction.

[kjj]

The short version is that coins don't "come from" anywhere.  If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet.  But when they came to your wallet, they didn't come from that place.

And that is for simple transactions, it can get worse.

Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work.

I think you are taking some metaphors too literally.

I think there such thing as "from" address(es), and we can see them for any given transaction.

Well, as long as you don't mind being wrong, you are free to keep thinking that. 

[niko]

The short version is that coins don't "come from" anywhere.  If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet.  But when they came to your wallet, they didn't come from that place.

And that is for simple transactions, it can get worse.

Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work.

I think you are taking some metaphors too literally.

I think there such thing as "from" address(es), and we can see them for any given transaction.

Well, as long as you don't mind being wrong, you are free to keep thinking that.  

Explain how this is wrong: every transaction (other than generation-only) includes the public key of the payer (and the ECDSA signature using the corresponding private key of the payer). Payer's public key is thus revealed, and "from" address is simply the RIPEMD-160(SHA-256(PubKey)).

Explicit example:



Of course, if there are multiple inputs, there will be multiple "from" addresses.

[kjj]

Explain how this is wrong: every transaction (other than generation-only) includes the public key of the payer (and the ECDSA signature using the corresponding private key of the payer). Payer's public key is thus revealed, and "from" address is simply the RIPEMD-160(SHA-256(PubKey)).

Explicit example:



Of course, if there are multiple inputs, there will be multiple "from" addresses.

Outputs have scripts, not addresses.  And the recognition that transactions have lists of inputs and outputs should give you pause before thinking that you can connect an output to an input, in general.

Look at these two transactions, and tell me what the "from" address for each one was.

997e5182...
0f463847...

P.S.  blockexplorer.com having a column titled "From Address" doesn't make it so.  And the tooltip note is wrong.

[niko]

Outputs have scripts, not addresses. 

Not sure how this relates to the question of (non)existence of "from" addresses.

And the recognition that transactions have lists of inputs and outputs should give you pause before thinking that you can connect an output to an input, in general.

Again, nothing to do with the issue discussed here. I never mentioned connecting an output to an input in the same transaction (the sum total needs to match, including miner's fees, that is all - no point connecting particular inputs to particular outputs). We agree there, but it is irrelevant.

Look at these two transactions, and tell me what the "from" address for each one was.

997e5182...
0f463847...

The first one seems to be a multisig attempt from  35nGJpcQr4pYVyFVR3BPbdaWUSk6NBryUD, discussed here.
The second one clearly lists all addresses associated with (many) inputs. These are the "from" addresses.

It's quite simple, can't we agree on this?

OP was asking about "from" addresses, but was told there was no such thing in Bitcoin. I claim this is false, as transaction inputs specify public keys which translate into corresponding addresses. The coins are thus sent from these addresses, in the sense that control (ownership) of coins is reassigned from these "from" addresses (and the corresponding key pairs) to the receiveing addresses (and the corresponding key pairs).

[Come-from-Beyond]

Outputs have scripts, not addresses.

Outputs have predicates, not scripts. 

[kjj]

The second one clearly lists all addresses associated with (many) inputs. These are the "from" addresses.

It's quite simple, can't we agree on this?

OP was asking about "from" addresses, but was told there was no such thing in Bitcoin. I claim this is false, as transaction inputs specify public keys which translate into corresponding addresses. The coins are thus sent from these addresses, in the sense that control (ownership) of coins is reassigned from these "from" addresses (and the corresponding key pairs) to the receiveing addresses (and the corresponding key pairs).

In doing so, you have redefined "from" to mean "the last address that it was sent to".  If muddling the two concepts works for you, then enjoy, I guess.

However, when people come here asking this question, they are trying to do something.  The something that they are doing is dangerous, and never the correct way to solve the (real) problem they have.  Typically, what they really want is a return address.  Bitcoin has no such concepts.  There is no return address, just like there is no sending address.  People working with bitcoin need to accept the system as it really is, not the way they want it to be.  They can choose not to, as you have, but they do so at their own peril, and I won't encourage them down that road.

Bitcoin transactions connect other transactions to scripts.  They do not connect addresses to addresses.  Just because you can sometimes (or even usually) find an address that controlled a now-redeemed transaction does not mean that the new transaction came from that address.  There is no general solution, because the concepts simply do not exist in the system.

Do you understand that?  You are finding things that exist in some transactions that have properties similar to the thing you are looking for, and you claim that they are the thing you are looking for.

What address did this little guy come from?

[aaaxn]

One transaction input is another transaction output. You claim input is not 'from address'. Isn't it equivalent to saying that previous transaction output is not 'to address'?

[DannyHamilton]

One transaction input is another transaction output. You claim input is not 'from address'. Isn't it equivalent to saying that previous transaction output is not 'to address'?

As I understand it, there is no "address" requirement in bitcoin on the "from" side or the "to" side.

A transaction output sets up a requirement for redeeming.  A transaction input satisfies the redeeming requirement of the previous transaction. Traditionally that requirement is usually a signature and public key from a private key that is associated with a hash value that we call an "address", but it doesn't always have to be.  As long as you can create a script that can be satisfied, and can provide the satisfying requirements in the input of a future transaction, you can transfer the value associated with the previous output into a new transaction to be associated with one or more new outputs.

In otherwords, although you can find many (most?) transactions satisfying a set of attributes that would seem to demonstrate something that you might try to call a "from address", bitcoin itself has no such concept, and to rely on such a concept is to set yourself up for future problems as additional transaction types (such as multi-sig) become more popular.

Many people think that their "coins" are a special unique string of numbers that they transfer around from wallet to wallet.  They believe that "their coins" actually exist inside their wallet file, and that when they back up that wallet, they are storing copies of "coins".  Everything they see in their daily use of bitcoin appears to fit this analogy for them.  It doesn't make it true, and if they relay on such a belief long enough, they'll eventually run into a situation that will cause them a problem.

[bukaj]

https://en.bitcoin.it/wiki/Script

[aaaxn]

In otherwords, although you can find many (most?) transactions satisfying a set of attributes that would seem to demonstrate something that you might try to call a "from address", bitcoin itself has no such concept, and to rely on such a concept is to set yourself up for future problems as additional transaction types (such as multi-sig) become more popular.

So we should also stop calling that you send coins to some address? Be consistent and stop relying on such misguided concepts. You will save yourself from problems in future ... you get the point ;]

Anyway, isn't it always possible to create return transaction in such a way that it's spending script will require exactly same information as first one? For example when you receive coins form multi sig transaction cannot you send it back in such way that they are able to spend with same multi sig requirements?

[DannyHamilton]

Anyway, isn't it always possible to create return transaction in such a way that it's spending script will require exactly same information as first one? For example when you receive coins form multi sig transaction cannot you send it back in such way that they are able to spend with same multi sig requirements?

And if there is more than one input with more than one requirement, along with multiple outputs of which you are only one?  Then how do you choose which input to use?

[kjj]

In otherwords, although you can find many (most?) transactions satisfying a set of attributes that would seem to demonstrate something that you might try to call a "from address", bitcoin itself has no such concept, and to rely on such a concept is to set yourself up for future problems as additional transaction types (such as multi-sig) become more popular.

So we should also stop calling that you send coins to some address? Be consistent and stop relying on such misguided concepts. You will save yourself from problems in future ... you get the point ;]

I'm glad you brought this up.  The bitcoin system itself has no addresses.  There is no "address" field in a transaction.  The address is a metaphor that we use to make it easier for humans to interact with the network clients.  If I give you an address, and you then "send coins to that address", what really happened is that your node is using a standard template to create a script based on the hash value encoded in the address.

Anyway, isn't it always possible to create return transaction in such a way that it's spending script will require exactly same information as first one? For example when you receive coins form multi sig transaction cannot you send it back in such way that they are able to spend with same multi sig requirements?

Well, sorta.  Depending on the script you are looking at, there are three ways it could go.  Case #1, no one is capable of redeeming the new transaction that you make.  Case #2, anyone is capable of redeeming it.  Case #3, one person (or group or whatever) is capable of redeeming it.  The system does not provide enough information in-band to distinguish the three cases.

The only concept that is universally meaningful when receiving a transaction is whether or not you received it.  If you need to make refunds or returns, you need to collect that information outside of the bitcoin system.

[aaaxn]

I'm glad you brought this up.  The bitcoin system itself has no addresses.  There is no "address" field in a transaction.  The address is a metaphor that we use to make it easier for humans to interact with the network clients.  If I give you an address, and you then "send coins to that address", what really happened is that your node is using a standard template to create a script based on the hash value encoded in the address.

Don't see a problem with making it easier for humans. Its not all humans fault that satoshi came up with this strange scripts design.

Well, sorta.  Depending on the script you are looking at, there are three ways it could go.  Case #1, no one is capable of redeeming the new transaction that you make.  Case #2, anyone is capable of redeeming it.  Case #3, one person (or group or whatever) is capable of redeeming it.  The system does not provide enough information in-band to distinguish the three cases.

Could you elaborate on that? On what information does it depend which case it is? I think that for standard send to address transaction I can just send fund to sender address and I am sure that only owner of this address private key can redeem it.

The only concept that is universally meaningful when receiving a transaction is whether or not you received it.  If you need to make refunds or returns, you need to collect that information outside of the bitcoin system.

Scripts was supposedly be powerful tool but in reality any non-standard scripts are forbidden and developers whitelist some kind scripts from time to time so in reality valid transactions types could just be enumerated in source and things would be much simpler.

[kjj]

I'm glad you brought this up.  The bitcoin system itself has no addresses.  There is no "address" field in a transaction.  The address is a metaphor that we use to make it easier for humans to interact with the network clients.  If I give you an address, and you then "send coins to that address", what really happened is that your node is using a standard template to create a script based on the hash value encoded in the address.

Don't see a problem with making it easier for humans. Its not all humans fault that satoshi came up with this strange scripts design.

The only concept that is universally meaningful when receiving a transaction is whether or not you received it.  If you need to make refunds or returns, you need to collect that information outside of the bitcoin system.

Scripts was supposedly be powerful tool but in reality any non-standard scripts are forbidden and developers whitelist some kind scripts from time to time so in reality valid transactions types could just be enumerated in source and things would be much simpler.

Scripts are there for a reason.  We rely on a small number of standard types right now, because they are hard to handle safely.  We need to take some time to learn how to work with them, and we will.  What we have now fills a lot of needs, but not all of them.

Well, sorta.  Depending on the script you are looking at, there are three ways it could go.  Case #1, no one is capable of redeeming the new transaction that you make.  Case #2, anyone is capable of redeeming it.  Case #3, one person (or group or whatever) is capable of redeeming it.  The system does not provide enough information in-band to distinguish the three cases.

Could you elaborate on that? On what information does it depend which case it is?

For case #1, the signature could be computed with a key that is now lost.  A new transaction would not have the same signature.  There are good reasons to never destroy keys, but as a recipient, you have no guarantee that the key to a previous transaction output still exists.

For case #2, the script could be a hashing puzzle, or some other device intended for a single use only.  The solution may become public when used, and thus anyone could collect repeats.

Case #3 is the usual case, using ECDSA where the key is retained forever.

[aaaxn]

Scripts are there for a reason.  We rely on a small number of standard types right now, because they are hard to handle safely.  We need to take some time to learn how to work with them, and we will.  What we have now fills a lot of needs, but not all of them.

I agree standard types does not cover all needs and that's why this list is extended in new versions. However we could achieve same thing with just updating big transaction type switch in code.

For case #1, the signature could be computed with a key that is now lost.  A new transaction would not have the same signature.  There are good reasons to never destroy keys, but as a recipient, you have no guarantee that the key to a previous transaction output still exists.

You don't have guarantee that recipient still holds key for address he sent you too.

For case #2, the script could be a hashing puzzle, or some other device intended for a single use only.  The solution may become public when used, and thus anyone could collect repeats.

Case #3 is the usual case, using ECDSA where the key is retained forever.

So in short: in every real world use of bitcoins it is possible.

[kjj]

Scripts are there for a reason.  We rely on a small number of standard types right now, because they are hard to handle safely.  We need to take some time to learn how to work with them, and we will.  What we have now fills a lot of needs, but not all of them.

I agree standard types does not cover all needs and that's why this list is extended in new versions. However we could achieve same thing with just updating big transaction type switch in code.

There are serious issues with such a model.

For case #1, the signature could be computed with a key that is now lost.  A new transaction would not have the same signature.  There are good reasons to never destroy keys, but as a recipient, you have no guarantee that the key to a previous transaction output still exists.

You don't have guarantee that recipient still holds key for address he sent you too.

True, but he gave you that address, so it is up to him to keep the key safe.  If you decide on your own to send coins to a random address, that would be different.  A judge would be able to see the difference immediately.  Would you pay a bill by mailing cash to an address that "you think" the biller owns?  Why would you send bitcoins to a pubkey that "you think" someone might own?

For case #2, the script could be a hashing puzzle, or some other device intended for a single use only.  The solution may become public when used, and thus anyone could collect repeats.

Case #3 is the usual case, using ECDSA where the key is retained forever.

So in short: in every real world use of bitcoins it is possible.

You may have missed it, but I've already agreed in this thread that if you want to assume a bunch of stuff that isn't necessarily really true, you can get away with a lot of stuff.  If you don't assume, and confine yourself to what really is, then you have to accept certain limitations.

[aaaxn]

There are serious issues with such a model.

What issues? There are advantages too. It would be more powerful than scripts and transactions could probably be smaller. Not to mention it would be easier to understand.

True, but he gave you that address, so it is up to him to keep the key safe.  If you decide on your own to send coins to a random address, that would be different.  A judge would be able to see the difference immediately.  Would you pay a bill by mailing cash to an address that "you think" the biller owns?  Why would you send bitcoins to a pubkey that "you think" someone might own?

It is not random address. It's address which coins came from. It's just a matter of convention. If law states that returning funds to sending address is good way to return funds then it's sender problem if he lost his key. I am not arguing we should certainly adopt one way or the other but I don't see why only one is correct.

[kjj]

There are serious issues with such a model.

What issues? There are advantages too. It would be more powerful than scripts and transactions could probably be smaller. Not to mention it would be easier to understand.

Less powerful, actually.  Not to mention needing to upgrade the entire network every time someone needs a new transaction type.

True, but he gave you that address, so it is up to him to keep the key safe.  If you decide on your own to send coins to a random address, that would be different.  A judge would be able to see the difference immediately.  Would you pay a bill by mailing cash to an address that "you think" the biller owns?  Why would you send bitcoins to a pubkey that "you think" someone might own?

It is not random address. It's address which coins came from. It's just a matter of convention. If law states that returning funds to sending address is good way to return funds then it's sender problem if he lost his key. I am not arguing we should certainly adopt one way or the other but I don't see why only one is correct.

Argh.  It is absolutely NOT the address that the coins came from, because there is no such thing.  If you want to argue about an imaginary system that we could have some day in the future, then in that system it could be a return address.  In the actual real bitcoin of today, there isn't one, and people should stop pretending that there is.

In bitcoin, you know if a payment happened.  You don't know where it came from, or who it came from.

[aaaxn]

Less powerful, actually.  Not to mention needing to upgrade the entire network every time someone needs a new transaction type.

Of course more powerful. Programming language is turing complete while scripts are not. And you could use some information about current network state. For example make transaction type which makes coins spendable only in blocks which number is even. Or when average transaction volume for N last block is greater than X. Use imagination.
As for updating network wasn't it needed for introducing multi sig transactions? So where is script advantage?

[Argh.  It is absolutely NOT the address that the coins came from, because there is no such thing.  If you want to argue about an imaginary system that we could have some day in the future, then in that system it could be a return address.  In the actual real bitcoin of today, there isn't one, and people should stop pretending that there is.

In bitcoin, you know if a payment happened.  You don't know where it came from, or who it came from.

I thought we are past this. There is sending address for 99%+ of all transaction because they have standard send to address inputs and outputs. I am talking about how it is in reality and ignoring rounding errors for convenience. Anyway I don't see any point arguing about it anymore because I admit you are technically right but in reality it doesn't matter.

[LvM]

Argh.  It is absolutely NOT the address that the coins came from, because there is no such thing.  If you want to argue about an imaginary system that we could have some day in the future, then in that system it could be a return address.  In the actual real bitcoin of today, there isn't one, and people should stop pretending that there is.

In bitcoin, you know if a payment happened.  You don't know where it came from, or who it came from.

Argh!
You could not better describe and admit the horrendous deficencies of current BTC !!

[kjj]

Argh.  It is absolutely NOT the address that the coins came from, because there is no such thing.  If you want to argue about an imaginary system that we could have some day in the future, then in that system it could be a return address.  In the actual real bitcoin of today, there isn't one, and people should stop pretending that there is.

In bitcoin, you know if a payment happened.  You don't know where it came from, or who it came from.

Argh!
You could not better describe and admit the horrendous deficencies of current BTC !!

Not a deficiency, troll.  Bitcoin has no notion of a sender, because it doesn't need that idea.  You are free to collect whatever out-of-band information your GAAP-obsessed brain thinks you need.

Are you also pissed that your paper money doesn't tell you who gave it to you?