Topic: how to get the "from address" from the bitcoin server client. (Read 1633 times)

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?

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

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?

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.

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


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.

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.

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.

There are serious issues with such a model.


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?


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.

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.

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

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

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.


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.

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.

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.

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.

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.


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.

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?

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?

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

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.

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

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?

Outputs have predicates, not scripts. 

Not sure how this relates to the question of (non)existence of "from" addresses.
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.

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).

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.

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.