3

Using bitcoin-cli decoderawtransaction I see results like...

{
  "txid": "d2183b3ea763f41a30ec5ba6fbf6e5f32e0ca6a5e8761249c533fe22190f71f1",
  "hash": "d2183b3ea763f41a30ec5ba6fbf6e5f32e0ca6a5e8761249c533fe22190f71f1",
  "version": 2,
  "size": 225,
  "vsize": 225,
   etc...

Why is the "hash" field necessary if the txid field is already a hash? (more specifically a double-pass through SHA-256 of the transaction's data)

I'm noticing in some transactions that txid and hash are equal, but in others they're not. Appreciate any explanation on the difference since I'm struggling to figure it out through Google and the source code comments.

Improve this question

1 Answer 1

Reset to default
5

Note that Bitcoin transactions don't actually contain the txid or hash within them. This is only part of the decoding output from Bitcoin Core.

The hash is there because of segwit. Segwit specifies that witness data for a segwit input (i.e. signatures, scripts) are not part of the txid. Those are in a separate area in the transaction. You can see this information decoded in the txinwitness field. So the hash is over the entire transaction, including this witness data, but the txid is not. Since transactions that do not have any segwit inputs do not have witness fields for their inputs, the txid and hash are the same.

Improve this answer
2
  • thank you - that makes sense regarding the hash field. But if txid is not included in the transaction, is it also not included in the vin/vout fields within a transaction?
    – d3wannabe
    Commented Jul 19, 2019 at 1:53
  • 2
    No, the txids for the outputs being spent are included. Just the txid of the transaction itself is not since you can calculate the txid from it.
    – Ava Chow ♦
    Commented Jul 19, 2019 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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