3

I'm having difficulty calculating txid for recent transactions. I followed bip-141 at https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

For the first transaction in the first block found in blk00165.dat (testnet), I get the following when I aggregate the required data to be hashed:

010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff2303cdb21400fe56ca615bfe8b8804000963676d696e6572343208020000000000000000ffffffff0220f68e11000000001976a91446868f669409e6e744c6a270767cc27e81220ead88ac0000000000000000266a24aa21a9ed5d06bb0f22a0ffa6d7c63f2769b13f917787554e1235f7eed140fe675ee29c050120000000000000000000000000000000000000000000000000000000000000000000000000

I also printed out the byte stream of the file and it matches. But when I double hash it, I get an invalid txid. Am I missing something for segwit transactions?

My code works for non-segwit transactions, tested with the first few transactions in the very first block.

Improve this question

1 Answer 1

Reset to default
7

The txid of a segwit transaction is computed by first dropping all the witnesses, and encoding it in legacy notation, and then computing the double-SHA256 hash of it.

This is the only possible way, as anything else wouldn't be compatible with old clients (which is required by it being a softfork).

Improve this answer
6
  • Now that makes a lot of sense... I was wondering why txid and wtxid were two separate things.
    – fon
    Commented Jul 19, 2019 at 22:28
  • Sorry for the intrusion, so the hash of transaction before segwit is calculated at the same mode of the transaction after segwit?
    – vincenzopalazzo
    Commented Jul 20, 2019 at 8:35
  • 3
    Yes, the definition of txid has not changed. Segwit simply added extra data to transactions that does not contribute to the txid.
    – Pieter Wuille
    Commented Jul 20, 2019 at 8:38
  • 1
    Another question on Segwit, if the Segwit was been introducing because the txid is malleability, how the softfork fix this problem if the hash is calculated to the same mode?
    – vincenzopalazzo
    Commented Jul 20, 2019 at 8:55
  • 2
    Because the malleable part (the signature data) is now segregated, and not contributing to the txid anymore. The place where signatures go in pre-segwit transactions is empty for segwit; it's still there, but only containing a dummy. The real signature is elsewhere.
    – Pieter Wuille
    Commented Jul 20, 2019 at 8:58

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.