<p>This is perfectly normal. The   <code>"vout":1</code> you see refers to the second output of one of the input transactions. </p>

<p>Say input transaction I funds the transaction T you are looking at. That means one of the outputs of transaction I funds the transaction T. This does <strong>not</strong> however imply that hte number of outputs of transaction T is dependent upon the number of outputs of transaction I.</p>

CC BY-SA 3.0
2016-07-15T10:35:46.910Z
Awesome ! I do not understand how to find the address of the creditor
max-lt
CC BY-SA 3.0
2016-07-15T09:47:34.727Z
2016-07-15T09:47:34.727Z
hartmut
<p>Bitcoin client returns something strange with this <a href="https://chainquery.com/bitcoin-api/getrawtransaction/90ff15e5a80593977fb2f6666de2860584d39ebc3a41f65a0a1fdc3a851aefda/1" rel="nofollow">transaction</a> (getrawtransaction 90f...fda 1) :
there is <strong>only one output</strong> address, and <strong>six input</strong> address. 
Yet, one of the input address <strong>targets a second output</strong> address ("vout": 1).</p>

<p><code>$ bitcoin-cli getrawtransaction 90ff15e5a80593977fb2f6666de2860584d39ebc3a41f65a0a1fdc3a851aefda 1
</code></p>

<pre><code>{
  "hex": "0100[...]000",
  "txid": "90ff15e5a80593977fb2f6666de2860584d39ebc3a41f65a0a1fdc3a851aefda",
  "size": 726,
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "0b086abe2602f870a2d93ed496b0558d5fc349c4504eb0d474cc4ca99b4b1308",
      "vout": 0,
      "scriptSig": {
        "asm": "304502202466ca9b80920af2f518962695dd31e35d5d688729dc17e52cf6d05369bca69b022100edd5e092b81d4b64001f1c437fd6a9fe710bfdbcbb0eb00fa9d66099ed50c671[ALL]",
        "hex": "48304502202466ca9b80920af2f518962695dd31e35d5d688729dc17e52cf6d05369bca69b022100edd5e092b81d4b64001f1c437fd6a9fe710bfdbcbb0eb00fa9d66099ed50c67101"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "a32363cff5c5663ee7625ec038d78fedd2060a25782f67d0608b9558dce43963",
      "vout": 0,
      "scriptSig": {
        "asm": "304402202991e2c0a6fedd64b6e2d0caa54b256aa689dcb75d3d92a53bf41b9305e152ab0220710bcc25136cdcfc233f33d5527227642e2bdaec64070847b1c2e44f1c6b17d2[ALL]",
        "hex": "47304402202991e2c0a6fedd64b6e2d0caa54b256aa689dcb75d3d92a53bf41b9305e152ab0220710bcc25136cdcfc233f33d5527227642e2bdaec64070847b1c2e44f1c6b17d201"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "e36f06a8dfe44c3d64be2d3fe56c77f91f6a39da4a5ffc086ecb5db9664e8583",
      "vout": 1,
      "scriptSig": {
        "asm": "304402206ff8c7fba70ac27df61abfb249200247c94c206095b486485cbc39752b97b51c02203466533aab833a47fef8600bcd92c54bd45a21d9f386e08188f094870c9aef11[ALL]",
        "hex": "47304402206ff8c7fba70ac27df61abfb249200247c94c206095b486485cbc39752b97b51c02203466533aab833a47fef8600bcd92c54bd45a21d9f386e08188f094870c9aef1101"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "3f5d810e62022ae5c3cd46131a2bc64cf92a5a9b3b9ac316a814bb47507616dc",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100de3dce233f69eae1d003a92213fd233112f80c331265bbe22994deeacf84bdbd02207c331411d3a62089b7c632a5e53c20d5d2e4de72235b60f1a3eb80f0f98c3f5a[ALL]",
        "hex": "483045022100de3dce233f69eae1d003a92213fd233112f80c331265bbe22994deeacf84bdbd02207c331411d3a62089b7c632a5e53c20d5d2e4de72235b60f1a3eb80f0f98c3f5a01"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "312eacd1cf17e131b33a3ad35c89a517bbf640a9ae06fdcf7977d06941cb2cae",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100add2e315ff749421aa5c204fc9d1ac6304b55337471e47b69be6433f9186aa4602202b97f5a29c1fe9b2a1acb5695369217c39d7a94fc3c8ed7cbb4ed4487694317b[ALL]",
        "hex": "483045022100add2e315ff749421aa5c204fc9d1ac6304b55337471e47b69be6433f9186aa4602202b97f5a29c1fe9b2a1acb5695369217c39d7a94fc3c8ed7cbb4ed4487694317b01"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "1704b85b190683be893af88515c6f3900aaef4c02067112f1d0d50fb39aa0999",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100bd60476ed58cf35ff5f8cd6157b18be18844dfbbb6cca265bcb0bd57a8f9818a0220296f5cb8757e0d1dafe8cd8e8ee0a330fe6b717227132fc13ed4508cdb3cd8bd[ALL]",
        "hex": "483045022100bd60476ed58cf35ff5f8cd6157b18be18844dfbbb6cca265bcb0bd57a8f9818a0220296f5cb8757e0d1dafe8cd8e8ee0a330fe6b717227132fc13ed4508cdb3cd8bd01"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 275.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91412ab8dc588ca9d5787dde7eb29569da63c3a238c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "12higDjoCCNXSA95xZMWUdPvXNmkAduhWv"
        ]
      }
    }
  ],
  "blockhash": "000000008c526b4821b66aa55980dd0c5c40a710fc45b11e4e2509c207cbc64f",
  "confirmations": 388004,
  "time": 1232392372,
  "blocktime": 1232392372
}
</code>
</pre>

<p>Moreover, <a href="https://blockchain.info/fr/tx/90ff15e5a80593977fb2f6666de2860584d39ebc3a41f65a0a1fdc3a851aefda" rel="nofollow">blockchain.info</a> does not seem to have been affected by that...</p>

<p>What can explain a such comportement ?</p>

<json-rpc>
Wrong getrawtransaction response?
max-lt
# Wrong getrawtransaction response?

(Asked by: username_0 on 2016-07-15)

Bitcoin client returns something strange with this [transaction](https://chainquery.com/bitcoin-api/getrawtransaction/90ff15e5a80593977fb2f6666de2860584d39ebc3a41f65a0a1fdc3a851aefda/1) (getrawtransaction 90f...fda 1) :
there is **only one output** address, and **six input** address.
Yet, one of the input address **targets a second output** address ("vout": 1).

`$ bitcoin-cli getrawtransaction 90ff15e5a80593977fb2f6666de2860584d39ebc3a41f65a0a1fdc3a851aefda 1`

```
{
  "hex": "0100[...]000",
  "txid": "90ff15e5a80593977fb2f6666de2860584d39ebc3a41f65a0a1fdc3a851aefda",
  "size": 726,
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "0b086abe2602f870a2d93ed496b0558d5fc349c4504eb0d474cc4ca99b4b1308",
      "vout": 0,
      "scriptSig": {
        "asm": "304502202466ca9b80920af2f518962695dd31e35d5d688729dc17e52cf6d05369bca69b022100edd5e092b81d4b64001f1c437fd6a9fe710bfdbcbb0eb00fa9d66099ed50c671[ALL]",
        "hex": "48304502202466ca9b80920af2f518962695dd31e35d5d688729dc17e52cf6d05369bca69b022100edd5e092b81d4b64001f1c437fd6a9fe710bfdbcbb0eb00fa9d66099ed50c67101"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "a32363cff5c5663ee7625ec038d78fedd2060a25782f67d0608b9558dce43963",
      "vout": 0,
      "scriptSig": {
        "asm": "304402202991e2c0a6fedd64b6e2d0caa54b256aa689dcb75d3d92a53bf41b9305e152ab0220710bcc25136cdcfc233f33d5527227642e2bdaec64070847b1c2e44f1c6b17d2[ALL]",
        "hex": "47304402202991e2c0a6fedd64b6e2d0caa54b256aa689dcb75d3d92a53bf41b9305e152ab0220710bcc25136cdcfc233f33d5527227642e2bdaec64070847b1c2e44f1c6b17d201"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "e36f06a8dfe44c3d64be2d3fe56c77f91f6a39da4a5ffc086ecb5db9664e8583",
      "vout": 1,
      "scriptSig": {
        "asm": "304402206ff8c7fba70ac27df61abfb249200247c94c206095b486485cbc39752b97b51c02203466533aab833a47fef8600bcd92c54bd45a21d9f386e08188f094870c9aef11[ALL]",
        "hex": "47304402206ff8c7fba70ac27df61abfb249200247c94c206095b486485cbc39752b97b51c02203466533aab833a47fef8600bcd92c54bd45a21d9f386e08188f094870c9aef1101"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "3f5d810e62022ae5c3cd46131a2bc64cf92a5a9b3b9ac316a814bb47507616dc",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100de3dce233f69eae1d003a92213fd233112f80c331265bbe22994deeacf84bdbd02207c331411d3a62089b7c632a5e53c20d5d2e4de72235b60f1a3eb80f0f98c3f5a[ALL]",
        "hex": "483045022100de3dce233f69eae1d003a92213fd233112f80c331265bbe22994deeacf84bdbd02207c331411d3a62089b7c632a5e53c20d5d2e4de72235b60f1a3eb80f0f98c3f5a01"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "312eacd1cf17e131b33a3ad35c89a517bbf640a9ae06fdcf7977d06941cb2cae",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100add2e315ff749421aa5c204fc9d1ac6304b55337471e47b69be6433f9186aa4602202b97f5a29c1fe9b2a1acb5695369217c39d7a94fc3c8ed7cbb4ed4487694317b[ALL]",
        "hex": "483045022100add2e315ff749421aa5c204fc9d1ac6304b55337471e47b69be6433f9186aa4602202b97f5a29c1fe9b2a1acb5695369217c39d7a94fc3c8ed7cbb4ed4487694317b01"
      },
      "sequence": 4294967295
    }, 
    {
      "txid": "1704b85b190683be893af88515c6f3900aaef4c02067112f1d0d50fb39aa0999",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100bd60476ed58cf35ff5f8cd6157b18be18844dfbbb6cca265bcb0bd57a8f9818a0220296f5cb8757e0d1dafe8cd8e8ee0a330fe6b717227132fc13ed4508cdb3cd8bd[ALL]",
        "hex": "483045022100bd60476ed58cf35ff5f8cd6157b18be18844dfbbb6cca265bcb0bd57a8f9818a0220296f5cb8757e0d1dafe8cd8e8ee0a330fe6b717227132fc13ed4508cdb3cd8bd01"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 275.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91412ab8dc588ca9d5787dde7eb29569da63c3a238c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "12higDjoCCNXSA95xZMWUdPvXNmkAduhWv"
        ]
      }
    }
  ],
  "blockhash": "000000008c526b4821b66aa55980dd0c5c40a710fc45b11e4e2509c207cbc64f",
  "confirmations": 388004,
  "time": 1232392372,
  "blocktime": 1232392372
}

```

Moreover, [blockchain.info](https://blockchain.info/fr/tx/90ff15e5a80593977fb2f6666de2860584d39ebc3a41f65a0a1fdc3a851aefda) does not seem to have been affected by that...

What can explain a such comportement ?

**Tags:** json-rpc


---

## 1 answers

### Answer by username_1 on 2016-07-15. Score: 1 | Accepted answer

This is perfectly normal. The `"vout":1` you see refers to the second output of one of the input transactions.

Say input transaction I funds the transaction T you are looking at. That means one of the outputs of transaction I funds the transaction T. This does **not** however imply that hte number of outputs of transaction T is dependent upon the number of outputs of transaction I.

> **Comments:**
> **username_0**: Awesome ! I do not understand how to find the address of the creditor  

---

