<p>From sipa on IRC (2023-01-06):</p>
<blockquote>
<p>jamesob: Probably dumb question, but why does <code>uint256::ToString()</code> (-&gt; <code>HexStr()</code>) print out the blob in reversed byte order?</p>
<p>sipa: Because that's what it has always done, really.</p>
<p>sipa: And people expect txids and block hashes in hex notation to be reserved.</p>
<p>sipa: Historically, that was because txids/block hashes were 256-bit numbers constructed by interpreting the double-sha256 output as a little-endian integer, and then printing it out for human consumption in hex (where humans expect numbers in big endian).</p>
<p>sipa: But now uint256 is just a byte array wrapper, the behavior is maintained because block hashes and txids are always printed in reverse.</p>
<p>sipa: (block hashes are still interpreted a little-endian numbers for the purpose of comparing PoW to the target, but that's handled by the arith_uint256 class now)</p>
</blockquote>

CC BY-SA 4.0
2023-01-12T10:11:37.477Z
2023-01-12T10:11:37.477Z
James O'Beirne
<p>When converting <code>uint256</code> (the datatype used to represent hashes) to string in Bitcoin Core, the <a href="https://github.com/bitcoin/bitcoin/blob/master/src/uint256.cpp#L19-L27" rel="noreferrer">bytes are reversed</a>. When debugging functional tests, this can create potential confusion when comparing hashes passed to script on the Python side and hashes naively printed from within Bitcoin Core's cpp.</p>
<p>Why are the bytes reversed when getting <code>HexStr()</code> for hashes in Bitcoin Core?</p>

CC BY-SA 4.0
2023-01-12T14:38:39.903Z
Glad to see you on Bitcoin StackExchange, James! I expect we might get a few questions on OP_VAULT in the coming months/years, so you picked an excellent time to join in on the fun.
Vojtěch Strnad
CC BY-SA 4.0
2023-01-13T13:23:03.080Z
Does this answer your question? [Why does the Bitcoin protocol use the little-endian notation?](https://bitcoin.stackexchange.com/questions/2063/why-does-the-bitcoin-protocol-use-the-little-endian-notation)
MCCCS
<bitcoin-core><bitcoind><bitcoin-core-development><hash><endianness>
Why does Bitcoin Core print SHA256 hashes (uint256) bytes in reverse order?
James O'Beirne
# Why does Bitcoin Core print SHA256 hashes (uint256) bytes in reverse order?

(Asked by: username_0 on 2023-01-12)

When converting `uint256` (the datatype used to represent hashes) to string in Bitcoin Core, the [bytes are reversed](https://github.com/bitcoin/bitcoin/blob/master/src/uint256.cpp#L19-L27). When debugging functional tests, this can create potential confusion when comparing hashes passed to script on the Python side and hashes naively printed from within Bitcoin Core's cpp.

Why are the bytes reversed when getting `HexStr()` for hashes in Bitcoin Core?

**Tags:** bitcoin-core, bitcoind, bitcoin-core-development, hash, endianness

> **Comments:**
> **username_1**: Glad to see you on Bitcoin StackExchange, username_0! I expect we might get a few questions on OP_VAULT in the coming months/years, so you picked an excellent time to join in on the fun.  
> **username_2**: Does this answer your question? [Why does the Bitcoin protocol use the little-endian notation?](https://bitcoin.stackexchange.com/questions/2063/why-does-the-bitcoin-protocol-use-the-little-endian-notation)  

---

## 1 answers

### Answer by username_0 on 2023-01-12. Score: 14

From sipa on IRC (2023-01-06):

> jamesob: Probably dumb question, but why does `uint256::ToString()` (-> `HexStr()`) print out the blob in reversed byte order?
>
> sipa: Because that's what it has always done, really.
>
> sipa: And people expect txids and block hashes in hex notation to be reserved.
>
> sipa: Historically, that was because txids/block hashes were 256-bit numbers constructed by interpreting the double-sha256 output as a little-endian integer, and then printing it out for human consumption in hex (where humans expect numbers in big endian).
>
> sipa: But now uint256 is just a byte array wrapper, the behavior is maintained because block hashes and txids are always printed in reverse.
>
> sipa: (block hashes are still interpreted a little-endian numbers for the purpose of comparing PoW to the target, but that's handled by the arith\_uint256 class now)


---

