<p>To get the full picture of <a href="https://blockchain.info/tx/1a558999f1360e95406c39ada43121fc2441ca5600e39f5d5a3bd3c494b9aae9" rel="nofollow">this transaction</a> (1a55...), you must also get information on the input transactions, <a href="https://blockchain.info/tx/a83dc6dc8e375eb9c63db531f298fd426b94f80167fc1d164a89b353442aa44a" rel="nofollow">a83d...</a> and <a href="https://blockchain.info/tx/a15332b9b61c2f1f8777efaaa5f652e0a4daf213fb266c2e8deef9479ece26f1" rel="nofollow">a153...</a>.</p>

<p>The input for a83d has <code>"vout" : 0</code>, which means it's the <em>first</em> output that we'll be spending here. If you pull up the info on a83d, you'll find that its first output was for 0.05 BTC to address 1QKj... Similarly, a153 with a <code>vout</code> of <code>1</code> means we'll spend the second output. The second output there was 0.00319234 BTC to address 1PK5... These are our input amounts and addresses. The <code>scriptSig</code> contains the public keys corresponding to these addresses and the signed messages allowing the transaction. It's worth noting that from these public keys, you can calculate the input addresses, but not the amounts.</p>

<p>The outputs are a little more straightforward: <code>value</code> is the amount, and the address is under <code>addresses</code>. These show that 0.05 BTC goes to 1BJC... and 0.00299234 BTC goes to 1RFK... Note that the outputs contain only addresses (in the raw form, they are the hexadecimal numbers like 70f2...), not public keys. The sum of inputs is a little larger than the sum of outputs. The difference, 0.0002 BTC here, is the transaction fee, that goes to the miner that finds a block with the transaction.</p>

<p>A likely interpretation of this transaction is that one person owns addresses 1QKj and 1PK5; he sent 0.05 BTC to 1BJC, and received his change at 1RFK.</p>

<p>For more details and explanations on how Bitcoin transactions work, see <a href="http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/" rel="nofollow">How the Bitcoin protocol actually works</a> by Michael Nielsen and the <a href="https://en.bitcoin.it/wiki/Transactions" rel="nofollow">Transactions</a> page on the wiki.</p>

CC BY-SA 3.0
2017-09-06T10:42:32.390Z
I am surprised this excellent answer not been even voted-up
Nick
CC BY-SA 3.0
2014-05-28T20:10:49.020Z
2014-05-28T20:10:49.020Z
Tim S.
<p>The addresses of Receiver is the one given in VOUT["scriptPubKey"]["addresses"] section.For the addresses of sender you need to get rawtransaction of VIN["txid"], and match the index of Vout with "n".
Here is <a href="https://bitcoin.stackexchange.com/questions/25540/how-to-get-the-input-address-from-vin-where-only-a-txid-is-given-insight-api/74721#74721">Python 2.7 implementation</a> of same, hope that helps</p>

CC BY-SA 4.0
2018-05-04T06:46:27.037Z
2018-05-04T06:46:27.037Z
Parishilan Rayamajhi
<p>For this particular transaction, there is NO SENDER. Notice the "coinbase" field in vin, it indicates this is newly generated coin, created via mining.</p>

CC BY-SA 3.0
2014-02-27T08:12:38.377Z
2014-02-27T08:12:38.377Z
uminatsu
<p>This is my very first dive into the actual transaction contents. I'm choosing a random transaction in the block chain to understand whats going on. </p>

<p>So, I see that this particular transaction has a single input, and a set of outputs. </p>

<p>What I <em>really</em> don't understand at this point is, how can I tell what the originating and ending addresses were, along with the transaction amount. </p>

<p>My confusion comes from not seeing the originating address (although I suspect that's me not understanding something fundamental) coupled with multiple recipients defined across a set of <code>vout</code>addresses.  </p>

<pre><code>{
"hex" : "01000000024aa42a4453b3894a161dfc6701f8946b42fd98f231b53dc6b95e378edcc63da8000000008c4930460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb8014104c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37fffffffff126ce9e47f9ee8d2e6c26fb13f2daa4e052f6a5aaef77871f2f1cb6b93253a1010000008b483045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d014104f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3dffffffff02404b4c00000000001976a91470f25592e7284f48ccddcc8ef9af83d48c47301a88ace2900400000000001976a9140495ef54c1276a4bf3e35e433d893857db344e7088ac00000000",
"txid" : "1a558999f1360e95406c39ada43121fc2441ca5600e39f5d5a3bd3c494b9aae9",
"version" : 1,
"locktime" : 0,
"vin" : [
    {
        "txid" : "a83dc6dc8e375eb9c63db531f298fd426b94f80167fc1d164a89b353442aa44a",
        "vout" : 0,
        "scriptSig" : {
            "asm" : "30460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb801 04c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37",
            "hex" : "4930460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb8014104c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37"
        },
        "sequence" : 4294967295
    },
    {
        "txid" : "a15332b9b61c2f1f8777efaaa5f652e0a4daf213fb266c2e8deef9479ece26f1",
        "vout" : 1,
        "scriptSig" : {
            "asm" : "3045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d01 04f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3d",
            "hex" : "483045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d014104f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3d"
        },
        "sequence" : 4294967295
    }
],
"vout" : [
    {
        "value" : 0.05000000,
        "n" : 0,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 70f25592e7284f48ccddcc8ef9af83d48c47301a OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a91470f25592e7284f48ccddcc8ef9af83d48c47301a88ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1BJCzAbdTe8cCSvd2Yr7RCAnHqfsixjVth"
            ]
        }
    },
    {
        "value" : 0.00299234,
        "n" : 1,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 0495ef54c1276a4bf3e35e433d893857db344e70 OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a9140495ef54c1276a4bf3e35e433d893857db344e7088ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1RFKRhk3nMhk7yyN687YtxKVfohtdm6Sc"
            ]
        }
    }
],
"blockhash" : "00000000000000007764778f17fc18d6051711507bbaeb503c2d4aba017f1445",
"confirmations" : 4,
"time" : 1393487217,
"blocktime" : 1393487217
</code></pre>

<p>}</p>

<p>Taking another transaction as an example, I had a look at its inputs to see if it would be possible to figure out the address from the previous transactions. What I ended up with was this:</p>

<pre><code>Current Transaction: 3846c2c5de2d6a3ea44d0d26d52cef2b33c9f44f3da1305e33905aebd3ba5795

Input 1 to Current Transaction:     70413306b48d8a1ce9b4d9a3500477cea1e42888c07f69d9f45f4785fde0e551 [0]
    Output: 14sbkc8jwphWvDczoBMY812nvpT7T8pp3t
    Output: 15R7vh1r5nrTB7uGg89pmP8grJKzpRVeTr
    Output: 129w8zn65WqkVmUbTQGnLojg6qu5vaNnvQ

Input 2 to Current Transaction: a97685efbed249543f34c22480609ea1851b4d4c76f7207db3de64b65206d037 [6]
    Output: 1AdVciiT8VoJiCn5nevnVQnzQFeyHKtgzU
    Output: 1A2UXf1wK4G7g6NquQu5VJzAt2hwBvakwc
    Output: 1NT9GeNPK7jW33b61Xv8CpRhfTwXXHrbsh
    Output: 1DNWZmsURXXyNchhj3An4em3UkHb7ux39L
    Output: 18rt5YDpzL7CuBSsCxQPSWg6xPu7UR6Dks 
    Output: 13aUL5mzLGLJKbfCBfJukRPmikau5aGHF3
    Output: 16ui1ZtnN1Ufgp9RHvp7jECbMPoMfEjLzW
    Output: 16ZgAzQZyvv6MWZALTUBcvNEiKARbjoMHZ    

Input 3 to Current Transaction: dc4ba3a246a479f7747a05fa56658f2521a9456689103a2df0015b538edaa7d7 [2]    
    Output: 1Pxh9sMK22d2QCU1quoFcgP2arxHgyaHeV
    Output: 1AxfD8QMrjbvD4SRWEBavYY1P6FfPhXpri
    Output: 14ZQsi7XWMBpXu8MRJdq23TJBymnsvMY4j
</code></pre>

<p>None of the previous inputs match. What am I missing?</p>

CC BY-SA 3.0
2014-02-27T08:03:28.757Z
I see that [the `vin` part of this may already have been answered](http://bitcoin.stackexchange.com/questions/3896/how-to-findout-the-sender-of-a-transaction?rq=1). I'll have a try of that.
TheMightyLlama
<bitcoind>
Any single transaction has vin and vout values. How can I tell the address of the originator and receiver?
TheMightyLlama
# Any single transaction has vin and vout values. How can I tell the address of the originator and receiver?

(Asked by: username_0 on 2014-02-27)

This is my very first dive into the actual transaction contents. I'm choosing a random transaction in the block chain to understand whats going on.

So, I see that this particular transaction has a single input, and a set of outputs.

What I *really* don't understand at this point is, how can I tell what the originating and ending addresses were, along with the transaction amount.

My confusion comes from not seeing the originating address (although I suspect that's me not understanding something fundamental) coupled with multiple recipients defined across a set of `vout`addresses.

```
{
"hex" : "01000000024aa42a4453b3894a161dfc6701f8946b42fd98f231b53dc6b95e378edcc63da8000000008c4930460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb8014104c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37fffffffff126ce9e47f9ee8d2e6c26fb13f2daa4e052f6a5aaef77871f2f1cb6b93253a1010000008b483045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d014104f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3dffffffff02404b4c00000000001976a91470f25592e7284f48ccddcc8ef9af83d48c47301a88ace2900400000000001976a9140495ef54c1276a4bf3e35e433d893857db344e7088ac00000000",
"txid" : "1a558999f1360e95406c39ada43121fc2441ca5600e39f5d5a3bd3c494b9aae9",
"version" : 1,
"locktime" : 0,
"vin" : [
    {
        "txid" : "a83dc6dc8e375eb9c63db531f298fd426b94f80167fc1d164a89b353442aa44a",
        "vout" : 0,
        "scriptSig" : {
            "asm" : "30460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb801 04c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37",
            "hex" : "4930460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb8014104c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37"
        },
        "sequence" : 4294967295
    },
    {
        "txid" : "a15332b9b61c2f1f8777efaaa5f652e0a4daf213fb266c2e8deef9479ece26f1",
        "vout" : 1,
        "scriptSig" : {
            "asm" : "3045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d01 04f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3d",
            "hex" : "483045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d014104f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3d"
        },
        "sequence" : 4294967295
    }
],
"vout" : [
    {
        "value" : 0.05000000,
        "n" : 0,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 70f25592e7284f48ccddcc8ef9af83d48c47301a OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a91470f25592e7284f48ccddcc8ef9af83d48c47301a88ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1BJCzAbdTe8cCSvd2Yr7RCAnHqfsixjVth"
            ]
        }
    },
    {
        "value" : 0.00299234,
        "n" : 1,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 0495ef54c1276a4bf3e35e433d893857db344e70 OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a9140495ef54c1276a4bf3e35e433d893857db344e7088ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1RFKRhk3nMhk7yyN687YtxKVfohtdm6Sc"
            ]
        }
    }
],
"blockhash" : "00000000000000007764778f17fc18d6051711507bbaeb503c2d4aba017f1445",
"confirmations" : 4,
"time" : 1393487217,
"blocktime" : 1393487217

```

}

Taking another transaction as an example, I had a look at its inputs to see if it would be possible to figure out the address from the previous transactions. What I ended up with was this:

```
Current Transaction: 3846c2c5de2d6a3ea44d0d26d52cef2b33c9f44f3da1305e33905aebd3ba5795

Input 1 to Current Transaction:     70413306b48d8a1ce9b4d9a3500477cea1e42888c07f69d9f45f4785fde0e551 [0]
    Output: 14sbkc8jwphWvDczoBMY812nvpT7T8pp3t
    Output: 15R7vh1r5nrTB7uGg89pmP8grJKzpRVeTr
    Output: 129w8zn65WqkVmUbTQGnLojg6qu5vaNnvQ

Input 2 to Current Transaction: a97685efbed249543f34c22480609ea1851b4d4c76f7207db3de64b65206d037 [6]
    Output: 1AdVciiT8VoJiCn5nevnVQnzQFeyHKtgzU
    Output: 1A2UXf1wK4G7g6NquQu5VJzAt2hwBvakwc
    Output: 1NT9GeNPK7jW33b61Xv8CpRhfTwXXHrbsh
    Output: 1DNWZmsURXXyNchhj3An4em3UkHb7ux39L
    Output: 18rt5YDpzL7CuBSsCxQPSWg6xPu7UR6Dks 
    Output: 13aUL5mzLGLJKbfCBfJukRPmikau5aGHF3
    Output: 16ui1ZtnN1Ufgp9RHvp7jECbMPoMfEjLzW
    Output: 16ZgAzQZyvv6MWZALTUBcvNEiKARbjoMHZ    

Input 3 to Current Transaction: dc4ba3a246a479f7747a05fa56658f2521a9456689103a2df0015b538edaa7d7 [2]    
    Output: 1Pxh9sMK22d2QCU1quoFcgP2arxHgyaHeV
    Output: 1AxfD8QMrjbvD4SRWEBavYY1P6FfPhXpri
    Output: 14ZQsi7XWMBpXu8MRJdq23TJBymnsvMY4j

```

None of the previous inputs match. What am I missing?

**Tags:** bitcoind

> **Comments:**
> **username_0**: I see that [the `vin` part of this may already have been answered](http://bitcoin.stackexchange.com/questions/3896/how-to-findout-the-sender-of-a-transaction?rq=1). I'll have a try of that.  

---

## 3 answers

### Answer by username_1 on 2014-05-28. Score: 4

To get the full picture of [this transaction](https://blockchain.info/tx/1a558999f1360e95406c39ada43121fc2441ca5600e39f5d5a3bd3c494b9aae9) (1a55...), you must also get information on the input transactions, [a83d...](https://blockchain.info/tx/a83dc6dc8e375eb9c63db531f298fd426b94f80167fc1d164a89b353442aa44a) and [a153...](https://blockchain.info/tx/a15332b9b61c2f1f8777efaaa5f652e0a4daf213fb266c2e8deef9479ece26f1).

The input for a83d has `"vout" : 0`, which means it's the *first* output that we'll be spending here. If you pull up the info on a83d, you'll find that its first output was for 0.05 BTC to address 1QKj... Similarly, a153 with a `vout` of `1` means we'll spend the second output. The second output there was 0.00319234 BTC to address 1PK5... These are our input amounts and addresses. The `scriptSig` contains the public keys corresponding to these addresses and the signed messages allowing the transaction. It's worth noting that from these public keys, you can calculate the input addresses, but not the amounts.

The outputs are a little more straightforward: `value` is the amount, and the address is under `addresses`. These show that 0.05 BTC goes to 1BJC... and 0.00299234 BTC goes to 1RFK... Note that the outputs contain only addresses (in the raw form, they are the hexadecimal numbers like 70f2...), not public keys. The sum of inputs is a little larger than the sum of outputs. The difference, 0.0002 BTC here, is the transaction fee, that goes to the miner that finds a block with the transaction.

A likely interpretation of this transaction is that one person owns addresses 1QKj and 1PK5; he sent 0.05 BTC to 1BJC, and received his change at 1RFK.

For more details and explanations on how Bitcoin transactions work, see [How the Bitcoin protocol actually works](http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/) by Michael Nielsen and the [Transactions](https://en.bitcoin.it/wiki/Transactions) page on the wiki.

> **Comments:**
> **username_2**: I am surprised this excellent answer not been even voted-up  

---

### Answer by username_3 on 2018-05-04. Score: 1

The addresses of Receiver is the one given in VOUT["scriptPubKey"]["addresses"] section.For the addresses of sender you need to get rawtransaction of VIN["txid"], and match the index of Vout with "n".
Here is [Python 2.7 implementation](https://bitcoin.stackexchange.com/questions/25540/how-to-get-the-input-address-from-vin-where-only-a-txid-is-given-insight-api/74721#74721) of same, hope that helps


---

### Answer by username_4 on 2014-02-27. Score: 1

For this particular transaction, there is NO SENDER. Notice the "coinbase" field in vin, it indicates this is newly generated coin, created via mining.


---

