Are transaction IDs on blockchain.info written backwards?

[r.willis]

Are transaction IDs (32-byte hashes of TX body) on blockchain.info written backwards, i.e. with bytes reversed?
Or it's mistake on my end, and I have it backwards myself?

[1715029165]

1715029165

[1715029165]

1715029165

[1715029165]

1715029165

[r.willis]

No one willing to check it?

[GoldenWings91]

TX ids aren't written backwards. Did you mean the block hash? The block hash goes through an endianess change.

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

[r.willis]

No, I did not mean block hash. Transaction hash (sha256(sha256(TX))), as used
in inv message and to identify transaction inputs.
Okay. Take this example TX message:

Code:

00000000  f9 be b4 d9 74 78 00 00  00 00 00 00 00 00 00 00  |....tx..........|
00000010  02 01 00 00 90 43 5a 1c  01 00 00 00 01 bd 21 ae  |.....CZ.......!.|
00000020  63 83 d4 8c 04 47 14 cb  6a 2f 48 83 4d ce fb 75  |c....G..j/H.M..u|
00000030  53 90 ad 7e 76 5e 48 fc  24 bf 59 0e 20 00 00 00  |S..~v^H.$.Y. ...|
00000040  00 8b 48 30 45 02 20 69  93 20 be 23 ff 4c eb 21  |..H0E. i. .#.L.!|
00000050  79 e7 b7 d1 ca 57 d7 1b  5e c5 20 91 45 63 ec b3  |y....W..^. .Ec..|
00000060  53 00 ee 1d a0 6a b7 02  21 00 f7 e4 39 fe 2f aa  |S....j..!...9./.|
00000070  83 c7 cd 72 cd 1f b1 79  8f 5a e6 eb cb 73 2e 1d  |...r...y.Z...s..|
00000080  81 c7 f6 30 75 9e 15 62  72 6b 01 41 04 e7 d5 08  |...0u..brk.A....|
00000090  09 71 d8 bb f0 d1 8f 25  35 ea 09 5f 63 16 6e a2  |.q.....%5.._c.n.|
000000a0  0f 75 75 71 91 64 1a ad  a4 3d 0c 26 c1 50 b7 f8  |.uuq.d...=.&.P..|
000000b0  ad de 67 3c ae e1 5c 59  f6 1f 9c 4a 31 11 e0 61  |..g<..\Y...J1..a|
000000c0  da fb cf 00 52 d2 9c 35  21 f1 52 dd f0 ff ff ff  |....R..5!.R.....|
000000d0  ff 02 40 4b 4c 00 00 00  00 00 19 76 a9 14 06 f1  |..@KL......v....|
000000e0  b6 70 79 1f 92 56 bf fc  89 8f 47 42 71 c2 2f 4b  |.py..V....GBq./K|
000000f0  b9 49 88 ac c2 fd 18 00  00 00 00 00 19 76 a9 14  |.I...........v..|
00000100  16 db fb 2a d4 f8 2c be  d2 0b 3a 32 44 94 00 f4  |...*..,...:2D...|
00000110  be 97 6d ef 88 ac 00 00  00 00                    |..m.......|

There is tx hash used as means to identify tx input:
bd21ae6383d48c044714cb6a2f48834dcefb755390ad7e765e48fc24bf590e20
If you search it on blockchain.info, you will find nothing. If you search it byte-reversed (200e59bf24fc485e767ead905375fbce4d83482f6acb1447048cd48363ae21bd),
you will find transaction in question. It seems unmistakeably reversed for me.   

[GoldenWings91]

Seems I was mistaken. I was looking at the txid and didn't realize the byte order was already changed.

[christop]

It's in Little Endian byte order (least-significant byte first) in the protocol, but it's written out in Big Endian byte order (most-significant byte first) as most other numbers in English normally are.

[r.willis]

Endianness have meaning when we talk about integers. tx ids are not integers, but array of bytes (chars).

[christop]

A transaction id is a very large integer. Or you could say that an integer is also an array of bytes.

[r.willis]

No, it is not.

Code:

32 	hash 	char[32] 	The hash of the referenced transaction. 

It makes no sense to treat (and print) it as integer.
But it seems like this strange custom (reversing represenation of tx ids) goes deep into the history of bitcoin. Someone (Satoshi?) implemented it that way, and everyone just follows.

[christop]

A cryptographic hash is a big integer. What C++ integer type would you use to store a 256-bit integer besides an array of a smaller integer type (char in this case)?

[r.willis]

Code:

A cryptographic hash function is a hash function; that is, an algorithm that takes an arbitrary block of data and returns a fixed-size [b]bit string[/b]

It's not integer, it's bit (byte) string.
Calculation of hash is defined with bit string operations, i.e. shifts and xors.

[Zeilap]

Code:

A cryptographic hash function is a hash function; that is, an algorithm that takes an arbitrary block of data and returns a fixed-size [b]bit string[/b]

It's not integer, it's bit (byte) string.
Calculation of hash is defined with bit string operations, i.e. shifts and xors.

Internally, the reference client represents all hashes as 256 bit integers (or 160 bit integers for RIPEMD hashes). It makes no sense to me either as the only arithmetic operation that needs to be performed is to compare the hash to the difficulty target when verifying a block, and this can be done with lexicographic ordering which is the default when comparing strings.

[Schleicher]

If you want to read the actual definition of the sha256 algorithm look here:
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
or here:
http://tools.ietf.org/html/rfc6234
The hash is supposed to be a 256bit integer.

[christop]

Code:

A cryptographic hash function is a hash function; that is, an algorithm that takes an arbitrary block of data and returns a fixed-size [b]bit string[/b]

It's not integer, it's bit (byte) string.
Calculation of hash is defined with bit string operations, i.e. shifts and xors.

SHA-256 (the hash function used to compute Bitcoin transaction IDs) treats the hash value as an integer.

Keep in mind that an integer is also a bit string in a binary computer, so Wikipedia's definition of a cryptographic hash function is accurate but incomplete when discussing a specific hash function like SHA-256.

[r.willis]

http://tools.ietf.org/html/rfc6234
The hash is supposed to be a 256bit integer.

Please provide exact citation. It talks about 8-, 32-, and 64-bit integers, but I see nothing about hash being 256bin integer.

SHA-256 (the hash function used to compute Bitcoin transaction IDs) treats the hash value as an integer.

Please provide credible citation.

[christop]

You're right, r.willis. The SHA spec does not explicitly point out that a SHA-256 has is a 256-bit integer.

However, as a programmer I tend to "read between the lines" and simplify specs to manage their complexity and try to understand them better. In the case of SHA, the spec mentions that all words are stored and represented in the Big-Endian order, so I came to the logical conclusion that SHA-256 outputs a 256-bit integer, with H0 being the most-significant 32-bit word and H7 the least-significant (H0 through H7 are appended from left to right).

It also simplifies understanding how the Bitcoin protocol treats the SHA-256 hash bit string--as an integer stored in Little Endian. This is consistent with the rest of the protocol as most every other integer is stored in the Little-Endian byte order (IP addresses and TCP port numbers being notable exceptions).

Dealing with the hash as an array of 32 char becomes straightforward: hash[0] is the least-significant digit (base-256 digit because a char is 8 bits wide) and hash[31] is the most-significant digit.

To print out the hash, it's a simple matter of printing out hash[31] through hash[0], as the Western convention is to write numbers in Big-Endian order.

[r.willis]

There is nothing little-endian in SHA-256. First byte is first byte, and should be printed as such (like in hex dump I provided, for example).
One approach to get rid of such inconsistency would be use of base58 encoding (which explicitly treats values as big-endian), with new version/application byte. It will be shorter, too.

[Zeilap]

There is nothing little-endian in SHA-256. First byte is first byte, and should be printed as such (like in hex dump I provided, for example).
One approach to get rid of such inconsistency would be use of base58 encoding (which explicitly treats values as big-endian), with new version/application byte. It will be shorter, too.

It wouldn't be shorter at all. With base 58, you have 58 possible values per byte, with a byte string you get 256 values per byte. It would only look shorter when printed.

[r.willis]

For human-readable form, I mean. Now they are printed as byte-reversed hex values.

[christop]

There is nothing little-endian in SHA-256. First byte is first byte, and should be printed as such (like in hex dump I provided, for example).
One approach to get rid of such inconsistency would be use of base58 encoding (which explicitly treats values as big-endian), with new version/application byte. It will be shorter, too.

If we consider the SHA-256 hash to be an integer, it can be stored in either byte order. The Bitcoin protocol stores it in Little Endian.

The integer in your example is 200e...21bd. In Little Endian byte order it is the byte sequence bd 21 ... 0e 20. This is exactly like storing/sending a smaller integer like 12345678 as 78 56 34 12 in Little Endian. The only difference is the number of bits.