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

[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?