r.willis (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
March 31, 2013, 10:00:59 AM |
|
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?
|
|
|
|
r.willis (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
March 31, 2013, 03:45:18 PM |
|
No one willing to check it?
|
|
|
|
|
r.willis (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
March 31, 2013, 04:43:59 PM |
|
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: 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
|
|
March 31, 2013, 07:48:35 PM |
|
Seems I was mistaken. I was looking at the txid and didn't realize the byte order was already changed.
|
|
|
|
christop
Member
Offline
Activity: 84
Merit: 10
|
|
March 31, 2013, 07:57:17 PM |
|
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.
|
Tips are always welcome: 17Z63hLi2ox4fCMhDqVJrLTJiXVcBMJpMo Alpaca socks donations: 1sockzDWcF8mrC59CgiN7HAJm6xL7TiRW
|
|
|
r.willis (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
March 31, 2013, 08:21:06 PM |
|
Endianness have meaning when we talk about integers. tx ids are not integers, but array of bytes (chars).
|
|
|
|
christop
Member
Offline
Activity: 84
Merit: 10
|
|
March 31, 2013, 08:52:42 PM |
|
A transaction id is a very large integer. Or you could say that an integer is also an array of bytes.
|
Tips are always welcome: 17Z63hLi2ox4fCMhDqVJrLTJiXVcBMJpMo Alpaca socks donations: 1sockzDWcF8mrC59CgiN7HAJm6xL7TiRW
|
|
|
r.willis (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
March 31, 2013, 09:28:11 PM |
|
No, it is not. 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
Member
Offline
Activity: 84
Merit: 10
|
|
March 31, 2013, 11:44:19 PM |
|
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)?
|
Tips are always welcome: 17Z63hLi2ox4fCMhDqVJrLTJiXVcBMJpMo Alpaca socks donations: 1sockzDWcF8mrC59CgiN7HAJm6xL7TiRW
|
|
|
r.willis (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
April 01, 2013, 06:25:11 AM |
|
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
|
|
April 01, 2013, 07:33:49 AM |
|
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.
|
|
|
|
|
christop
Member
Offline
Activity: 84
Merit: 10
|
|
April 01, 2013, 03:29:10 PM |
|
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.
|
Tips are always welcome: 17Z63hLi2ox4fCMhDqVJrLTJiXVcBMJpMo Alpaca socks donations: 1sockzDWcF8mrC59CgiN7HAJm6xL7TiRW
|
|
|
r.willis (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
April 01, 2013, 06:32:28 PM |
|
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
Member
Offline
Activity: 84
Merit: 10
|
|
April 01, 2013, 07:31:59 PM |
|
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.
|
Tips are always welcome: 17Z63hLi2ox4fCMhDqVJrLTJiXVcBMJpMo Alpaca socks donations: 1sockzDWcF8mrC59CgiN7HAJm6xL7TiRW
|
|
|
r.willis (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
April 01, 2013, 07:54:35 PM |
|
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
|
|
April 01, 2013, 08:58:12 PM |
|
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 (OP)
Jr. Member
Offline
Activity: 42
Merit: 11
|
|
April 01, 2013, 09:16:58 PM |
|
For human-readable form, I mean. Now they are printed as byte-reversed hex values.
|
|
|
|
christop
Member
Offline
Activity: 84
Merit: 10
|
|
April 01, 2013, 09:26:28 PM |
|
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.
|
Tips are always welcome: 17Z63hLi2ox4fCMhDqVJrLTJiXVcBMJpMo Alpaca socks donations: 1sockzDWcF8mrC59CgiN7HAJm6xL7TiRW
|
|
|
|