Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type 1 and type 2 transactions have yParity, not v #27727

Closed
MicahZoltu opened this issue Jul 15, 2023 · 3 comments · Fixed by #27744
Closed

Type 1 and type 2 transactions have yParity, not v #27727

MicahZoltu opened this issue Jul 15, 2023 · 3 comments · Fixed by #27744
Assignees

Comments

@MicahZoltu
Copy link
Contributor

V *hexutil.Big `json:"v"`

Geth currently is returning transactions that have a v value even when that doesn't make sense. EIP-2930 and EIP-1559 declare a yParity property on those transactions which is defined as "The parity (0 for even, 1 for odd) of the y-value of a secp256k1 signature." v is not defined anywhere in either of those EIPs and what one might put in a variable called v is incredibly ambiguous as it could be any of:

  1. yParity + 27
  2. yParity + 35 + 2 * chainId
  3. yParity (what I think geth is doing)

While I advocate for fixing the source code to use yParity instead of v for type 1 and 2 transactions internally so the code is more readable and follows the specification closer, what actually matters here is that the JSON-RPC should be including a yParity in any transaction response with a type 1 or type 2 transaction.

For backward compatibility, it seems reasonable to continue to include a v value that contains whatever it contains now, with perhaps some plan (or not) to eventually remove it.

@fjl fjl self-assigned this Jul 15, 2023
@anti-fjl
Copy link

This is such an important bug report. Why wasn't this found earlier? Would love to fix this ASAP..

@fjl
Copy link
Contributor

fjl commented Jul 15, 2023

Go ahead then!

@anti-fjl
Copy link

Would love to, but I'm off-code on this issue...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants