txid and hash question | Bitcointalksearch.org

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Dabs on October 03, 2019, 02:23:32 PM

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.

Dabs

legendary

Activity: 3416

Merit: 1912

The Concierge of Crypto

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.

warrior4jesus

newbie

Activity: 6

Merit: 0

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.

Quote from: achow101 on October 03, 2019, 10:11:26 AM

Quote from: warrior4jesus on October 03, 2019, 09:48:22 AM

Quote from: Coding Enthusiast on October 03, 2019, 09:37:53 AM

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

warrior4jesus

newbie

Activity: 6

Merit: 0

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.

Quote from: Coding Enthusiast on October 03, 2019, 10:20:48 AM

Quote from: warrior4jesus on October 03, 2019, 09:48:22 AM

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.

Coding Enthusiast

legendary

Activity: 1042

Merit: 2805

Bitcoin and C♯ Enthusiast

Quote from: warrior4jesus on October 03, 2019, 09:48:22 AM

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: warrior4jesus on October 03, 2019, 09:48:22 AM

Quote from: Coding Enthusiast on October 03, 2019, 09:37:53 AM

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

warrior4jesus

newbie

Activity: 6

Merit: 0

Quote from: Coding Enthusiast on October 03, 2019, 09:37:53 AM

"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?

Coding Enthusiast

legendary

Activity: 1042

Merit: 2805

Bitcoin and C♯ 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

newbie

Activity: 6

Merit: 0

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?

Topic: txid and hash question (Read 207 times)