I made two raw transactions. One was generated by ethereumjs-tx, the other by MyEtherWallet. They are identical until about the last seventh of the way through. Is there a way to work out what caused the differences?



4 Answers 4


You may want to try using the "unsign()" function in the ethereumjs-tx-sign library to inspect all the data contained in each of your raw transaction values.. and compare the contents.

You may find that it comes down to fixing an oversight in properly encoding all of the input parameters used when generating the raw transaction. A missing '0x' can wreak havoc.

  • 1
    I believe this is wrong. The raw transactions only differ on the signature part and the signatures are non-deterministic, so the transactions are supposed to be non-deterministic and thus different every time you create a new signed raw transaction even with the same inputs and using the same program. Dec 29, 2017 at 17:39
  • 1
    The unsign() function will reveal that the data in the two raw transactions are the same except for the signature parts. Dec 30, 2017 at 13:49

There is quite a lot going on here so bear with me.

Your raw transactions include a signature and signatures are non-deterministic, meaning that they contain a random element. This is the reason for the raw transactions being different. They only differ on the signature part. If you create a signed raw transactions twice for the same private key, input and using the same program, you should also get two different outputs.

To see why and how they differ, you must first know how raw transactions are encoded. A transaction is the RLP-encoding of these fields:

RLP(T_n, T_p, T_g, T_t, T_v, T_d, T_w, T_r, T_s)

RLP is a way of encoding an arbitrary datastructure into a byte array specified in Ethereum Yellow Paper, Appendix B.

The last three elements specify a point on an ECDSA curve. This point has been generated by the signing algorithm and the signing algorithm takes a random number when performing the signature. If this random number was not used, it would be possible to derive the private key from the signatures.

The two raw transactions differ only in the T_w, T_r, and T_s fields.

For the first transaction, the last three fields are:

26 [T_w]

a0 [length indication of T_r]
31e4a61cdbf1a802ba9176e35083ed0ed8593fd130e32f0f650919653177a516 [T_r]

a0 [length indication of T_s]
416d5c3d315e26e4db24226b0ab6927315150185404c133a5097fcf2a9aaa527 [T_s]

For the second transaction, the last three fields are:

1c [T_w]

a0 [length indication of T_r]
beb2c5b5fa47345a4df29e02d1fb746b59357fa21b44a4766994731229cb107d [T_r]

a0 [length indication of T_s]
2fd57c9e32d253ae86982dbcc66c30b5108d9b4ecb76eb84c92c55a3c889f5f8 [T_s]

That being said, the T_w values indicate that two different signing schemes have been used here. The T_w=0x1c is the original signature scheme whereas the T_w=0x26 is the EIP 155 signature scheme. Both signature schemes are valid and will be accepted on the Ethereum blockchain. EIP 155 was invented to protect against replay attacks and it is a newer way of signing an Ethereum transaction.

  • This should be the accepted answer. Good explanation!
    – q9f
    Dec 29, 2021 at 15:45

another possible cause (that was just reported) is that there may be in issue with the output generated by ethereumjs-tx when a chainId is specified. TBD..

  • The chainid did seem to be involved. I fixed the issue by removing the 1 from var tx = new Transaction(null, 1) and declaring later by tx.chanId = 1
    – Joe
    Jul 26, 2017 at 15:01
  • 1
    chainId is stored by tx as an internal value: tx._chainId.. it sounds like you didn't assign a value and it defaulted to the pre-EIP 155 behavior.. which is effectively assigning {chainID: 0}. The EIP 155 spec itself seems a little unclear on exactly how r and s should be encoded. Waiting for some clarification.. as right now ethereumjs-tx is setting the values to zero-length Buffers.. which seems wrong.. but the example (output) and some of the discussion implies that the RLP encoded values are correct.
    – Etherer
    Jul 27, 2017 at 1:36
  • PPS) the Transaction() constructor only accepts a single parameter.. chainId wouldn't be passed as an integer to a 2nd parameter.. it would be included in the hash table passed in the first.
    – Etherer
    Jul 27, 2017 at 1:41
  • oops.. I'd never used (or looked at) "MyEtherWallet" prior to just now. Does it even support a chainId field? Quick look.. but I don't see that as an input field.. so maybe the tool is pre- EIP 155.. which makes sense that its output would only match ethereumjs-tx when no chainId is specified.
    – Etherer
    Jul 27, 2017 at 1:46

“Creating offline/raw transactions with Go-Ethereum” @akshay_111meher https://medium.com/@akshay_111meher/creating-offline-raw-transactions-with-go-ethereum-8d6cc8174c5d

This is something off-track for your questions. However, you can clearly get transaction structure in this blog

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.