txid and hash question

[warrior4jesus]

On some transactions the txid and hash have the same value as each other and on other transactions they have different values. Why is this?

[1714967341]

1714967341

[1714967341]

1714967341

[1714967341]

1714967341

[1714967341]

1714967341

[1714967341]

1714967341

[Coding Enthusiast]

"Hash" is the result that you get from the hash function (double SHA256) and transaction ID is the hexadecimal representation of the that but in bitcoin we reverse it first and then encode it using base-16. So they are not exactly the same although they both represent the same value.
For example if your hash is { 1, 2, 3 } your txid is going to be 0x030201 (3 bytes is chosen for brevity otherwise length is 32 bytes).

[warrior4jesus]

"Hash" is the result that you get from the hash function (double SHA256) and transaction ID is the hexadecimal representation of the that but in bitcoin we reverse it first and then encode it using base-16. So they are not exactly the same although they both represent the same value.
For example if your hash is { 1, 2, 3 } your txid is going to be 0x030201 (3 bytes is chosen for brevity otherwise length is 32 bytes).

Thanks for your response.

Ok, they represent the same value. But sometimes they look the same. Reversed and encoded in base 16 just happens to get the same result as double SHA256?

[achow101]

"Hash" is the result that you get from the hash function (double SHA256) and transaction ID is the hexadecimal representation of the that but in bitcoin we reverse it first and then encode it using base-16. So they are not exactly the same although they both represent the same value.
For example if your hash is { 1, 2, 3 } your txid is going to be 0x030201 (3 bytes is chosen for brevity otherwise length is 32 bytes).

Thanks for your response.

Ok, they represent the same value. But sometimes they look the same. Reversed and encoded in base 16 just happens to get the same result as double SHA256?

No, that's completely wrong. It has nothing to do with the encoding.

Before segwit, the txid was the hash of the entire transaction. For non-segwit transactions, this is still true. But after segwit, some new data was added to transactions. This is not hashed as part of the txid, only those parts that were part of the non-segwit transaction format are hashed. The hash field was introduced for segwit as the hash of the entire segwit transaction.

When you see the txid and hash are the same, the transaction is non-segwit and both the txid and hash are hashing the entire transaction. When they are different, the transaction is a segwit transaction and txid is hashing some parts of the transaction while hash is hashing all of it.

[Coding Enthusiast]

Ok, they represent the same value. But sometimes they look the same. Reversed and encoded in base 16 just happens to get the same result as double SHA256?

Are you sure you are looking at correct values?
Here is an example transaction link on block explorer

The raw bytes of this transaction is:

Code:

01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0704ffff001d0104ffffffff0100f2052a0100000043410496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858eeac00000000

You can use this online tool to compute SHA256 of hexadecimal input: https://cryptii.com/pipes/hash-function click on the drop down dots and select duplicate to compute it twice. It should look like this: https://i.imgur.com/LWXpRIA.jpg
As you can see the result is going to be:

Code:

982051fd1e4ba744bbbe680e1fee14677ba1a3c3540bf7b1cdb606e857233e0e

Now if you look at that link from block explorer you can see that the txid is:

Code:

0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098

that is the hash result in reverse.

edit: Of course I forgot about SegWit, if the transaction has any witness, it has to be stripped off before hashing it as @achow101 pointed out.

[warrior4jesus]

I am looking at my own node via rpc and printing the entire tx object and this is what I am seeing. Sometimes the values are the same and sometimes not. I am writing my own blockchain explorer and want to understand what the data means.

Ok, they represent the same value. But sometimes they look the same. Reversed and encoded in base 16 just happens to get the same result as double SHA256?

Are you sure you are looking at correct values?
Here is an example transaction link on block explorer

The raw bytes of this transaction is:

Code:

01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0704ffff001d0104ffffffff0100f2052a0100000043410496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858eeac00000000

You can use this online tool to compute SHA256 of hexadecimal input: https://cryptii.com/pipes/hash-function click on the drop down dots and select duplicate to compute it twice. It should look like this: https://i.imgur.com/LWXpRIA.jpg
As you can see the result is going to be:

Code:

982051fd1e4ba744bbbe680e1fee14677ba1a3c3540bf7b1cdb606e857233e0e

Now if you look at that link from block explorer you can see that the txid is:

Code:

0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098

that is the hash result in reverse.

[warrior4jesus]

Yes. The tx's that have different values have an array in the object called [txinwitness]. The tx's where they have the same value do not have a [txinwitness] array. Thank you.

"Hash" is the result that you get from the hash function (double SHA256) and transaction ID is the hexadecimal representation of the that but in bitcoin we reverse it first and then encode it using base-16. So they are not exactly the same although they both represent the same value.
For example if your hash is { 1, 2, 3 } your txid is going to be 0x030201 (3 bytes is chosen for brevity otherwise length is 32 bytes).

Thanks for your response.

Ok, they represent the same value. But sometimes they look the same. Reversed and encoded in base 16 just happens to get the same result as double SHA256?

No, that's completely wrong. It has nothing to do with the encoding.

Before segwit, the txid was the hash of the entire transaction. For non-segwit transactions, this is still true. But after segwit, some new data was added to transactions. This is not hashed as part of the txid, only those parts that were part of the non-segwit transaction format are hashed. The hash field was introduced for segwit as the hash of the entire segwit transaction.

When you see the txid and hash are the same, the transaction is non-segwit and both the txid and hash are hashing the entire transaction. When they are different, the transaction is a segwit transaction and txid is hashing some parts of the transaction while hash is hashing all of it.

[Dabs]

Can you tell if an address that has received coins is a segwit address? I'm talking about those that begin with 3, also known as Legacy compatible segwit address, or wrapped segwit address.

I understand any coins sent to addresses that begin with bc1q are segwit transactions because that is the native segwit address format.

There are still some services that can't send to those, so if you use them, you have to give the addresses that begin with 3.

[achow101]

Can you tell if an address that has received coins is a segwit address? I'm talking about those that begin with 3, also known as Legacy compatible segwit address, or wrapped segwit address.

I understand any coins sent to addresses that begin with bc1q are segwit transactions because that is the native segwit address format.

There are still some services that can't send to those, so if you use them, you have to give the addresses that begin with 3.

Only if coins have been sent from that address. Only then can you look at a spending transaction and see if the redeemScript is a segwit script. Otherwise, you cannot.