Which of the two is correct order for signing the transaction?

[webtricks]

Consider the following unsigned raw transaction (just an example):

Code:

0100000001a2a3b7744d9021efaa94a08a54c385373fa9381203dabf317d9a83efecb76470000000001976a9143104a52d281de138aa47e944d1acc3288b9598c588acfdffffff0140420f00000000001976a914e84d6c709afa87d7f93315af93f0804cd08cd34b88ac00000000

The double SHA-256 hash of the above is (A):

Code:

ae6d2bc786fcafbcd39696276bb6539564eefdbc2f54099da4a273db5c467e8b

Hash with reverse bytes (B):

Code:

8b7e465cdb73a2a49d09542fbcfdee649553b66b279696d3bcaffc86c72b6dae

My question is: which of the above hash is signed for creating DER-encoded signature - A or B?

[1715535421]

1715535421

[1715535421]

1715535421

[1715535421]

1715535421

[pooya87]

My question is: which of the above hash is signed for creating DER-encoded signature - A or B?

The first one, meaning the actual 32 bytes that you get from your SHA256 function as the result of hashing the input [twice]. The second one is more like a "string" that bitcoin uses to show hashes and has no usages.

P.S. There is a mistake in what you are hashing, it appears that you have replaced the only input's signature with the pubkey script that is being spent (which is the correct step for spending P2PKH outputs) but you haven't added the SIGHASHTYPE flag at the end.

[webtricks]

My question is: which of the above hash is signed for creating DER-encoded signature - A or B?

The first one, meaning the actual 32 bytes that you get from your SHA256 function as the result of hashing the input [twice]. The second one is more like a "string" that bitcoin uses to show hashes and has no usages.

Okay thanks for the information. I read the other way around somewhere and got confused. I was wondering if bytes are reversed then why my application is working perfectly.

P.S. There is a mistake in what you are hashing, it appears that you have replaced the only input's signature with the pubkey script that is being spent (which is the correct step for spending P2PKH outputs) but you haven't added the SIGHASHTYPE flag at the end.

Yeah! I know. I just randomly picked input and addresses from the recent block, pasted those in Coinbin online tool and created the transaction. That's why I wrote - 'just an example'. In my real application, I do account for additional 4-bytes SIGHASHTYPE code.

[NotATether]

AFAIK, programs don't have to worry about which direction they write fields in DER-encoded files, because A would be the representation in little endian on everything running an x86 processor. B would be the typical way you send byte arrays across the network because the network order is big endian so in other words the hash that was created needs to be "flipped over" while going across the network and then flipped back when it reaches the other host. So all clients only ever see A.

[pooya87]

AFAIK, programs don't have to worry about which direction they write fields in DER-encoded files, because A would be the representation in little endian on everything running an x86 processor. B would be the typical way you send byte arrays across the network because the network order is big endian so in other words the hash that was created needs to be "flipped over" while going across the network and then flipped back when it reaches the other host. So all clients only ever see A.

Hashes are also sent as is over the network without any kind of flipping. You can read more about it on P2P networking part of dev docs. For example if your hash is 123 you send it as 123 and use it everywhere as 123 but show it to user in UI as 321.
The only other place when endianness is important is when converting a hash to an integer such as converting block header hashes to a BigInt to compare with difficulty target and you use little endian conversion there.

[NotATether]

Hashes are also sent as is over the network without any kind of flipping. You can read more about it on P2P networking part of dev docs. For example if your hash is 123 you send it as 123 and use it everywhere as 123 but show it to user in UI as 321.

What I don't understand is why does the UI reverse the hash when it displays it to users if it uses the original version everywhere else? Wouldn't this be misleading? 

[pooya87]

What I don't understand is why does the UI reverse the hash when it displays it to users if it uses the original version everywhere else? Wouldn't this be misleading? 

Because the original design by Satoshi was like that and although it is not in the protocol (as consensus rules or anything like that) it became kind of an standard.

I believe the reason for this behavior lies in the class used to hold the hash data, it is a UInt256 (as I said above when we convert hash to integer we use little-endian notation) so hashes are treated as integers already and are reversed when represented.

[webtricks]

AFAIK, programs don't have to worry about which direction they write fields in DER-encoded files, because A would be the representation in little endian on everything running an x86 processor. B would be the typical way you send byte arrays across the network because the network order is big endian so in other words the hash that was created needs to be "flipped over" while going across the network and then flipped back when it reaches the other host. So all clients only ever see A.

That I know but I wasn't asking about DER-encoding. My query was for ECDSA signature.

Here's the steps for calculating ECDSA signature (wikipedia):


As you can see, z is taken as the L_n leftmost bits of 'e' where  L_n is the bit length of the group order n. So, 'e' i.e. hash of message to be signed has to be in the specific order.