The transaction ID calculation is correct. For the signing, the arguments are still RLP encoded (the dummy "v" for EIP-155 is a bit special, see below).
Take this live transaction as an example. It has the following parameters.
nonce = 0 [RLP: 0x80]
gasPrice = 50000000000 wei (0x0BA43B7400) [RLP: 85 0BA43B7400]
gasLimit = 21000 (0x5208) [RLP: 82 5208]
to = 0x7917bc33eea648809c285607579c9919fb864f8f [RLP: 94 7917bc33eea648809c285607579c9919fb864f8f]
value = 1050000000000000 wei (0x03BAF82D03A000) [RLP: 87 03BAF82D03A000]
data = <empty> [RLP: 80]
v = 018080 (this is a place-holder value before signing, see EIP-155)
Then the input parameters for the hash is the RLP of the concatenation:
EB80850BA43B7400825208947917bc33eea648809c285607579c9919fb864f8f8703BAF82D03A00080018080
And the hash value for the signing is:
python3
>>> from Crypto.Hash import keccak
>>> keccak_hash=keccak.new(digest_bits=256)
>>> txn=bytearray.fromhex('EB80850BA43B7400825208947917bc33eea648809c285607579c9919fb864f8f8703BAF82D03A00080018080')
>>> keccak_hash.update(bytes(txn))
<Crypto.Hash.keccak.Keccak_Hash object at 0x10fb6e2e8>
>>> print(keccak_hash.hexdigest())
which gives the result
a4060d01d4add248db470b4121616cbe5b2015daf328809000ec9a1d0954d649
For the transaction ID, do Keccak hash on the final raw transaction bytes (RLP encoded as you mentioned, which are also readable from Etherscan) and it will give the same result as shown on Etherscan.
The miners need to know everything about the transaction. The signature requires hashing using the private key. That does not mean that the RLP-encoded tx requires hashing all together but only some components of the transaction (tx). The confusion comes that once these components (require hashing) are generated the signed transaction is required to be RLP-encoded again for the miners to mine.
Therefore, the answer would be that no RLP-encoded transaction is not hashed before being transmitted into the blockchain. But before being transmitted the unsigned transaction needs to be signed (which involves hashing) then it is RLP-encoded then transmitted.
Best Answer
you are supposed to sign the transaction hash. the hash is 32 bytes.
the hash is returned by
Hash()function of Ethereum API and it is a complex function which will depend on block number. the block number will tell what kind of fork is Ethereum currently on (London,Berlin, EIP155, etc). Depending on Ethereum fork, the process of generating these 32 bytes (the hash) you need to sign will be different, and of course it will be rlp-encoded internally (the order/amount of fields varies depending on the fork).the signature must be produced by ECDSA algorithm and comply with its format (as the standard specifies). these are the R/S/V fields which are set by the API after your transaction is signed (by common libraries we all use)
all of this stuff is already done by the libraries so you just have to call the appropriate functions to avoid reinventing the wheel