Transaction Signing & Hashing

Question

I've been looking through EthereumJ, Trying to understand how transaction hashing and signing works.

From what I can tell from the code, the signature is created by signing the hash of the RLP encoded transaction. The reason I'm confused, however, is because the hash is generated from the r and s values of the signature along with the rest. Considering those r and s values don't exist yet, how would they be included?

A bit more digging into the code looks like two different hashes are generated. One "raw" hash, in which the r and s values are simply empty byte arrays, which is the hash that gets signed, and then one actual hash, which includes the generated r and s values.

Is this understanding correct? Why bother including the signature in the signing process? As in, why doesn't the signature simply sign the hash of the non-signature elements of the transaction? Why does the "raw" hash include the v r and s values (even though the r and s are empty)?

Answer 1

The RLP encoded transaction with empty byte arrays for r, s was the original hash preimage. By EIP155 a value in the v field was added to protect signatures against replay attacks meaning that signatures on the Ethereum Classic blockchain would not also be valid for the same transaction on the Ethereum blockchain. The v field thus serves a double purpose: protect against replay attacks and enable public key recovery from the signature as explained here.

By EIP155 the hash preimage was changed to include the chain ID (prevents replay attacks on other Ethereum forks/testnet) and also zero-values (encoded as 80 in RLP), as temporary r, s values. Once the signature is calculated, the r, s values from the signature, along with the recovery bit, are inserted into the final transaction hex, thus creating the signed transaction.

It is hard for me to answer why EIP155 changes the hash preimage from no r,s fields to empty r,s fields. The specification does not explain why this change was made.

Prior to EIP155, the signature was:

ECDSA_secp256k1(private_key, Keccak256(RLP(nonce, gasPrice, gasLimit, To, Value, Data)))

With EIP155, the signature is:

ECDSA_secp256k1(private_key, Keccak256(RLP(nonce, gasPrice, gasLimit, To, Value, Data, v, r, s))),

where r, s is the RLP-encoding of the list [0x00]. This is encoded as 0x80.

The network accepts both kinds of signature.

The transaction ID (TXID) is calculated from the signed transaction. So if you in the code see a hash value being calculated from something containing the signature, this is the TXID.