Is there a relatively painless way to get a transaction's input(s)?

[Satosh¡ Slot]

I have accomplished to retreive the input address(es) with blockchain.info's API and it works fairly well for web applications, to prepopulate withdraw address fields etc, but it would be nice to be able to get this straight from bitcoind RPC calls. This is supposedly possible through viewing raw transactions, but I never got it to work. Anyone else tried to accomplish this?

[1715310135]

1715310135

[1715310135]

1715310135

[1715310135]

1715310135

[1715310135]

1715310135

[kjj]

Input address?  What's that?  I don't remember seeing that in the specs anywhere.

[Satosh¡ Slot]

Input address?  What's that?  I don't remember seeing that in the specs anywhere.

I mean what is generally called "input" or "inputs", basically the hash(es) from where the bitcoins in a transaction are taken. In blockchain.info it's returned like this:

Code:

"inputs":[
		{
		"prev_out":{
				"hash":"a3e2bcc9a5f776112497a32b05f4b9e5b2405ed9",...
				}
		}
]

I'm new to raw transactions as you can see.

[DannyHamilton]

Transaction inputs are previous outputs.  They don't have addresses.  They just have a transaction hash and an index.

If you want a "withdrawal address", you should ask your users for one.  It is a VERY BAD idea to try to guess at a withdrawal address based on bad assumptions from a transaction and blockchain history.  The fact that there are other services that use this VERY BAD idea does not make it a good idea.

[gweedo]

Take the input go to the transaction that it's hash points to, get outputs of that transactions. Then using vout go to that in the output array, get the address.

[Foxpup]

Suppose the input does not refer to any previous transactions at all? What then? (If you don't know why this might be the case, you shouldn't be trying to interpret transactions in this way. I mean, you shouldn't be doing it anyway, but now you have one more reason not to.)

[gweedo]

Suppose the input does not refer to any previous transactions at all? What then? (If you don't know why this might be the case, you shouldn't be trying to interpret transactions in this way. I mean, you shouldn't be doing it anyway, but now you have one more reason not to.)

That means they are newly mined and wouldn't have come from an address.

[Foxpup]

Suppose the input does not refer to any previous transactions at all? What then? (If you don't know why this might be the case, you shouldn't be trying to interpret transactions in this way. I mean, you shouldn't be doing it anyway, but now you have one more reason not to.)

That means they are newly mined and wouldn't have come from an address.

That question wasn't directed at you.

[BitEscrow]

Take the input go to the transaction that it's hash points to, get outputs of that transactions. Then using vout go to that in the output array, get the address.

  You literally made that up. GTFO with your FUD.

 Really, not one person here has fully answered the question.

[gweedo]

Take the input go to the transaction that it's hash points to, get outputs of that transactions. Then using vout go to that in the output array, get the address.

  You literally made that up. GTFO with your FUD.

 Really, not one person here has fully answered the question.

Wait what? Put your bitcoind in to txindex=1, and reindex the blockchain and then you can use getrawtransaction to get the information. No FUD here.

[DannyHamilton]

Take the input go to the transaction that it's hash points to, get outputs of that transactions. Then using vout go to that in the output array, get the address.

  You literally made that up. GTFO with your FUD.

 Really, not one person here has fully answered the question.

Go away troll.

Foxpup and I both gave the correct answer (It is a very bad idea to try to guess at a withdrawal address from a transaction.  The method is unreliable and will lead to long term problems.)

gweedo gave the technical answer on how to make a best guess from the information available in the blockchain. His method will work most of the time for a standard single signature transaction when the bitcoins aren't sent from a web-hosted shared bitcoin storage service.