Skip to content

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

@MicahZoltu

Description

@MicahZoltu

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions