Why do we reverse the byte order transaction hashes and block hashes?

[tobasco]

Why do we reverse the byte order hashes when searching for transactions and blocks from bitcoin-cli and blockchain explorers?

When you hash transaction data or a block header, you get a hash digest. This hash digest is used internally in bitcoin for referring to previous TXIDs in serialized transaction data, and for previous block hashes in block headers.

However, when we come to search for a specific transaction or block from the command line, the byte order is reversed. Why is this? Wouldn't it be much easier to use the same byte order as the one that comes out of the hash function and is used internally in bitcoin?

[DannyHamilton]

https://en.wikipedia.org/wiki/Endianness

big-endianness is the dominant ordering in networking protocols (IP, TCP, UDP). Conversely, little-endianness is the dominant ordering for processor architectures (x86, most ARM implementations) and their associated memory. File formats can use either ordering; some formats use a mixture of both

[tobasco]

https://en.wikipedia.org/wiki/Endianness

big-endianness is the dominant ordering in networking protocols (IP, TCP, UDP). Conversely, little-endianness is the dominant ordering for processor architectures (x86, most ARM implementations) and their associated memory. File formats can use either ordering; some formats use a mixture of both

Thanks for the Wiki link, but I'm still unsure.

Everything inside serialized transaction data can be considered to be in little-endian, where the txids used are in the default byte order that comes out of the hash function. These are sometimes referred to being in little-endian too.

So why do we convert hashes to big-endian when searching for transactions and blocks, when internally everything else is in little-endian?

[pooya87]

nobody knows why because this is a decision that the creator (Satoshi) made and to my knowledge there is no comment from him saying why.
however, it probably has something to do with the fact that hashes are interpreted as "numbers" (uint256), for example a block header hash is interpreted as a number to compare it with the target for the difficulty calculation purpose. and in writing we write numbers in big endian notation hence the endian-swap for representing them in GUI and using the non-reversed in code under the hood.
probably since uint256 is used elsewhere too (such as representation of a transaction ID) that reversing effect also happens there.

[tobasco]

nobody knows why because this is a decision that the creator (Satoshi) made and to my knowledge there is no comment from him saying why.
however, it probably has something to do with the fact that hashes are interpreted as "numbers" (uint256), for example a block header hash is interpreted as a number to compare it with the target for the difficulty calculation purpose. and in writing we write numbers in big endian notation hence the endian-swap for representing them in GUI and using the non-reversed in code under the hood.
probably since uint256 is used elsewhere too (such as representation of a transaction ID) that reversing effect also happens there.

Thank you.