4

It seems like "n" is the index, is that true? If that is the case, why is the "n" key necessary?

Example:

bitcoin-cli getrawtransaction b13b4765e46228f3239858c9f18e766b72bed24a56c52b9692e7f021c376e7ce 1

One of the resulting vouts:

  "vout": [
    {
      "value": 0.40000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 a88433dd5e9fcee779efdea952e397cf3bfe8aac OP_EQUAL",
        "hex": "a914a88433dd5e9fcee779efdea952e397cf3bfe8aac87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "3H43pNLbFEU1tWNwZeWxmrLwrLzAxwiC4b"
        ]
      }
    },
...

Since it's an array, couldn't you just use the array index? Seems redundant, but i'm sure there's a reason. Thanks

6

Since it's an array, couldn't you just use the array index? Seems redundant, but i'm sure there's a reason. Thanks

Yes, you could. In fact, that is how n is calculated since it isn't actually stored in the transaction. n is only provided as a convenience so that those constructing raw transactions do not need to count possibly hard to read JSON lines in order to get the output index for use in the input of another transaction.

6

The vout index (n) that you see after calling decoderawtransaction is added by bitcoind. It is not present in the raw transaction data.

If you manually decode the serialized tx for your example, you get this for the output section:

02  # Number of outputs
# value lockscript_length lockscript
005a620200000000 17 a914a88433dd5e9fcee779efdea952e397cf3bfe8aac87 
# value lockscript_length lockscript
c587841500000000 19 76a91402952d768c840f30a49e20af5bd4219210a14d2488ac

Notice how there is no index field. It is simply calculated by the node when deserializing the transaction.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.