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.

比尔盖子
  • 155
  • 9
fon
  • 77
  • 1
  • 6

1 Answers1

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).

Pieter Wuille
  • 105,497
  • 9
  • 194
  • 308
  • Now that makes a lot of sense... I was wondering why txid and wtxid were two separate things. – fon Jul 19 '19 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 Jul 20 '19 at 08: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 Jul 20 '19 at 08: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 Jul 20 '19 at 08: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 Jul 20 '19 at 08:58
  • Thanks so much, the my question is stupid because the reason was write in the BIP 0141, sorry – vincenzopalazzo Jul 20 '19 at 09:04