<p>The strings you posted are technically transaction <em>IDs</em> not transaction <em>hashes</em> and have to be reversed to get that &quot;actual hash&quot;. In bitcoin when hashes are printed as strings they are reversed. The actual hashes you should use are <code>d61dcc0e13256adb725861971b4bae753859ee61e406392305a4fddc54b55721</code>|<code>9fc661192944aa19aa9a1d097b30f9505aba500634b04d0f6725c0fdbb486cfe</code> When this is hashed twice it gives the following result: <code>647188084df0b2add9aee678e994cf971ac165d01dae5ab7efb1da6b3ae62410</code> since we print hashes in reverse it becomes &quot;1024...7164&quot; which is what you got from <code>SHA256D64</code>.</p>

CC BY-SA 4.0
2021-06-24T14:40:47.397Z
Thank you. You are right. The `GetHex` is doing the reverse of the hash to be printed using `ToString`. May I know the rationale behind why the transaction ID/`ToString` is reverse of the actual transaction hash?
explore
CC BY-SA 4.0
2021-06-24T15:32:00.753Z
I suppose this is the case for blockhash as well, which is `00000000000000000024fb37364cbf81fd49cc2d51c09c75c35433c3a1945d04` . If this is byte reversed to get the "actual hash", it starts with `045d..0000`. How does `CheckProofOfWork` work? How is this "actual hash" less than the target difficulty set for the block? I see `UintToArith256` copying word by word without much change other than endian-ness. Could you please provide clarity?
explore
CC BY-SA 4.0
2021-06-24T23:49:18.173Z
I got part of the answer [here](https://bitcointalk.org/index.php?topic=5201170.0)
explore
CC BY-SA 4.0
2021-07-24T18:27:49.077Z
The reason is this: SHA256 outputs a byte array, but in early versions of the Bitcoin software, that byte array was interpreted as a number - in little endian (least significant digit first). In the RPC output, those numbers are printed for human consumption in hex, with the most significant digit first (which matters; otherwise, block hashes would have their 0s at the end, which wouldn't look like "small" numbers).
Pieter Wuille
CC BY-SA 4.0
2024-11-05T22:37:49.870Z
Woah, I did not know this. Cool.
djangofan
CC BY-SA 4.0
2021-06-24T08:29:13.877Z
2021-06-24T08:29:13.877Z
Coding Enthusiast
<p>The tool you are linking to is hashing <em>text</em>, Bitcoin hashes are of <em>bytes</em>.</p>

CC BY-SA 4.0
2021-06-24T01:44:13.827Z
I used hex version in the tool
explore
CC BY-SA 4.0
2021-06-24T01:51:16.350Z
I used shasum and I get a different result :) I am definitely missing something fundamental.

```
x@instance1:~/backup$ echo -n 2157b554dcfda405233906e461ee593875ae4b1b97615872db6a25130ecc1dd6fe6c48bbfdc025670f4db0340650ba5a50f9307b091d9aaa19aa44291961c69f|xxd -r -p | shasum -b | awk '{print $1}'

41ca9dd2793aa443509251d3c90f1a3669d1b65e

x@instance1:~/backup$ echo -n 41ca9dd2793aa443509251d3c90f1a3669d1b65e |xxd -r -p | shasum -b | awk '{print $1}'

54daec3b996b6fcd0d04f70bdac2067b86e44e55

x@instance1:~/backup$

```
explore
CC BY-SA 4.0
2021-06-24T01:31:52.023Z
2021-06-24T01:31:52.023Z
Claris
<p>I am trying to go through the code to check the merkle tree hash computation done by <code>BlockMerkleRoot</code> in <strong>bitcoin core</strong>. The hash computed using online tools by appending transaction hashes is different from the ones computed by <code>SHA256D64</code> of <code>BlockMerkleRoot</code>. I am sure I am missing something. Could someone throw light on this?</p>
<p><strong>Details:</strong>
Looking at block <strong><a href="https://bitaps.com/500000?page=1" rel="nofollow noreferrer">500000</a></strong>:</p>
<p>appending coinbase hash <em>2157b554dcfda405233906e461ee593875ae4b1b97615872db6a25130ecc1dd6</em> with the first transaction hash <em>fe6c48bbfdc025670f4db0340650ba5a50f9307b091d9aaa19aa44291961c69f</em> and computing <a href="https://emn178.github.io/online-tools/sha256.html" rel="nofollow noreferrer">sha256</a> gives <em>0387276cdb563dc923e945f8e68596e3556756d2f2119b9b67905658b73afcb2</em> and doing another sha256 gives <em>1c0a7630e70d2b39b15585ec19c13c6f0a729a6501f5396dd75f75cb3aa4d110</em> which is different from the one returned by <code>SHA256D64</code> which is <em>1024e63a6bdab1efb75aae1dd065c11a97cf94e978e6aed9adb2f04d08887164</em>.</p>

<bitcoin-core><bitcoin-core-development><hash><merkle-tree><sha256>
Merkle tree hash - Computing hash manually doesnt match the one computed by SHA256D64
explore
# Merkle tree hash - Computing hash manually doesnt match the one computed by SHA256D64

(Asked by: username_0 on 2021-06-23)

I am trying to go through the code to check the merkle tree hash computation done by `BlockMerkleRoot` in **bitcoin core**. The hash computed using online tools by appending transaction hashes is different from the ones computed by `SHA256D64` of `BlockMerkleRoot`. I am sure I am missing something. Could someone throw light on this?

**Details:**
Looking at block **[500000](https://bitaps.com/500000?page=1)**:

appending coinbase hash *2157b554dcfda405233906e461ee593875ae4b1b97615872db6a25130ecc1dd6* with the first transaction hash *fe6c48bbfdc025670f4db0340650ba5a50f9307b091d9aaa19aa44291961c69f* and computing [sha256](https://emn178.github.io/online-tools/sha256.html) gives *0387276cdb563dc923e945f8e68596e3556756d2f2119b9b67905658b73afcb2* and doing another sha256 gives *1c0a7630e70d2b39b15585ec19c13c6f0a729a6501f5396dd75f75cb3aa4d110* which is different from the one returned by `SHA256D64` which is *1024e63a6bdab1efb75aae1dd065c11a97cf94e978e6aed9adb2f04d08887164*.

**Tags:** bitcoin-core, bitcoin-core-development, hash, merkle-tree, sha256


---

## 2 answers

### Answer by username_1 on 2021-06-24. Score: 0

The strings you posted are technically transaction *IDs* not transaction *hashes* and have to be reversed to get that "actual hash". In bitcoin when hashes are printed as strings they are reversed. The actual hashes you should use are `d61dcc0e13256adb725861971b4bae753859ee61e406392305a4fddc54b55721`|`9fc661192944aa19aa9a1d097b30f9505aba500634b04d0f6725c0fdbb486cfe` When this is hashed twice it gives the following result: `647188084df0b2add9aee678e994cf971ac165d01dae5ab7efb1da6b3ae62410` since we print hashes in reverse it becomes "1024...7164" which is what you got from `SHA256D64`.

> **Comments:**
> **username_0**: Thank you. You are right. The `GetHex` is doing the reverse of the hash to be printed using `ToString`. May I know the rationale behind why the transaction ID/`ToString` is reverse of the actual transaction hash?  
> **username_0**: I suppose this is the case for blockhash as well, which is `00000000000000000024fb37364cbf81fd49cc2d51c09c75c35433c3a1945d04` . If this is byte reversed to get the "actual hash", it starts with `045d..0000`. How does `CheckProofOfWork` work? How is this "actual hash" less than the target difficulty set for the block? I see `UintToArith256` copying word by word without much change other than endian-ness. Could you please provide clarity?  
> **username_0**: I got part of the answer [here](https://bitcointalk.org/index.php?topic=5201170.0)  
> **username_2**: The reason is this: SHA256 outputs a byte array, but in early versions of the Bitcoin software, that byte array was interpreted as a number - in little endian (least significant digit first). In the RPC output, those numbers are printed for human consumption in hex, with the most significant digit first (which matters; otherwise, block hashes would have their 0s at the end, which wouldn't look like "small" numbers).  
> **username_3**: Woah, I did not know this. Cool.  

---

### Answer by username_4 on 2021-06-24. Score: 0

The tool you are linking to is hashing *text*, Bitcoin hashes are of *bytes*.

> **Comments:**
> **username_0**: I used hex version in the tool  
> **username_0**: I used shasum and I get a different result :) I am definitely missing something fundamental.  ``` x@instance1:~/backup$ echo -n 2157b554dcfda405233906e461ee593875ae4b1b97615872db6a25130ecc1dd6fe6c48bbfdc025670f4db0340650ba5a50f9307b091d9aaa19aa44291961c69f|xxd -r -p | shasum -b | awk '{print $1}'  41ca9dd2793aa443509251d3c90f1a3669d1b65e  x@instance1:~/backup$ echo -n 41ca9dd2793aa443509251d3c90f1a3669d1b65e |xxd -r -p | shasum -b | awk '{print $1}'  54daec3b996b6fcd0d04f70bdac2067b86e44e55  x@instance1:~/backup$  ```  

---

