1

when doing e.g. a blockByNumber rpc request I am getting a result like this from parity: https://gist.github.com/ligi/fbc7061d93f087cf0eb0f4db83d1fced

what is puzzling me that some transactions have:

chainId":null

and some have

"chainId":"0x1"

I do not see the pattern when either variant is returned. geth does not contain the chainId there at all. Can someone enlighten me what is going on there? Is this a bug or am I missing some pattern/background?

Improve this question
2
  • 2
    is it possible some of the transactions are EIP155 compliant and some are network agnostic?
    – Mircea Nistor
    Commented Nov 29, 2019 at 12:50
  • 2
    this is exactly right - all of the transactions with null chainid also have a 'v' of 0x1c or 0x1b - 27 or 28
    – Joshua Mir
    Commented Nov 29, 2019 at 13:16

1 Answer 1

Reset to default
3

ChainId can be considered to be derived from the signature of a transaction, as described in EIP 155 - in the case of all of these transactions, they have the previous transaction format, where chainId is not present, which you can verify by checking the v value of these transactions (they are all 27 or 28, 0x1c or 0x1b).

Improve this answer
1
  • Thanks - this makes sense. Bit crazy how many people still sign without EIP155
    – ligi
    Commented Nov 29, 2019 at 23:45

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.