<p>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.</p>

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

CC BY-SA 4.0
2019-07-19T22:28:26.950Z
Now that makes a lot of sense... I was wondering why txid and wtxid were two separate things.
fon
CC BY-SA 4.0
2019-07-20T08:35:17.750Z
Sorry for the intrusion, so the hash of transaction before segwit is calculated at the same mode of the transaction after segwit?
vincenzopalazzo
CC BY-SA 4.0
2019-07-20T08:38:10.830Z
Yes, the definition of txid has not changed. Segwit simply added extra data to transactions that does not contribute to the txid.
Pieter Wuille
CC BY-SA 4.0
2019-07-20T08:55:20.717Z
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
CC BY-SA 4.0
2019-07-20T08:58:57.367Z
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
CC BY-SA 4.0
2019-07-20T09:04:17.783Z
Thanks so much, the my question is stupid because the reason was write in the BIP 0141, sorry
vincenzopalazzo
CC BY-SA 4.0
2019-07-19T21:49:35.227Z
2019-07-19T21:49:35.227Z
Pieter Wuille
<p>I'm having difficulty calculating txid for recent transactions. I followed bip-141 at <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki</a></p>

<p>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:</p>

<blockquote>
  <p>010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff2303cdb21400fe56ca615bfe8b8804000963676d696e6572343208020000000000000000ffffffff0220f68e11000000001976a91446868f669409e6e744c6a270767cc27e81220ead88ac0000000000000000266a24aa21a9ed5d06bb0f22a0ffa6d7c63f2769b13f917787554e1235f7eed140fe675ee29c050120000000000000000000000000000000000000000000000000000000000000000000000000</p>
</blockquote>

<p>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?</p>

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

<segregated-witness><transaction-id>
How to calculate txid for segwit transactions?
fon
# How to calculate txid for segwit transactions?

(Asked by: username_0 on 2019-07-19)

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.

**Tags:** segregated-witness, transaction-id


---

## 1 answers

### Answer by username_1 on 2019-07-19. Score: 7 | Accepted answer

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

> **Comments:**
> **username_0**: Now that makes a lot of sense... I was wondering why txid and wtxid were two separate things.  
> **username_2**: Sorry for the intrusion, so the hash of transaction before segwit is calculated at the same mode of the transaction after segwit?  
> **username_1**: Yes, the definition of txid has not changed. Segwit simply added extra data to transactions that does not contribute to the txid.  
> **username_2**: 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?  
> **username_1**: 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.  
> **username_2**: Thanks so much, the my question is stupid because the reason was write in the BIP 0141, sorry  

---

