ethers.js: getTransaction() error

Ethers Version

v6 latest

Search Terms

No response

Describe the Problem

v5 working fine v6 error ethers.getTransaction() return error: TypeError: yParity mismatch

Code Snippet

v5
provider = new providers.WebSocketProvider( 'wss://rpc.gnosischain.com/wss' )
let transaction = await provider.getTransaction(transactionHash).catch( e => { log( {level: 'fatal', message: 'getTransaction', transactionHash, error: e.data } ) } )

v6
provider = new ethers.WebSocketProvider( 'wss://rpc.gnosischain.com/wss' )
let transaction = await provider.getTransaction(transactionHash).catch( e => { log( {level: 'fatal', message: 'getTransaction', transactionHash, error: e } ) } )

Contract ABI

na

Errors

error: TypeError: yParity mismatch

Environment

node.js (older than v12)

Environment (Other)

No response

About this issue

Original URL
State: closed
Created a year ago
Comments: 16 (4 by maintainers)

Commits related to this issue

Fixes bug in yParity handling. Fixes #3835. I think. Note: I didn't test, made this change in a browser, but I'm pretty sure this or something very much like it will fix #3835. — committed to MicahZoltu/ethers.js by MicahZoltu a year ago
More robust support for Signatures with less standard parameter values (#3835, #4228). — committed to ethers-io/ethers.js by ricmoo a year ago
[Snyk] Upgrade ethers from 5.7.2 to 6.8.0 (#175) <p>This PR was automatically created by Snyk using the credentials of a real user.</p><br /><h3>Snyk has created this PR to upgrade ethers from 5.7.... — committed to Woodpile37/EIPs by Woodpile37 8 months ago
[Snyk] Upgrade ethers from 5.7.2 to 6.8.0 (#201) <p>This PR was automatically created by Snyk using the credentials of a real user.</p><br /><h3>Snyk has created this PR to upgrade ethers from 5.7.... — committed to Woodpile37/EIPs by Woodpile37 8 months ago
More robust support for Signatures with less standard parameter values (#3835, #4228). — committed to Woodpile37/ethers.js by ricmoo a year ago
More robust support for Signatures with less standard parameter values (#3835, #4228). — committed to Woodpile37/ethers.js by ricmoo a year ago

Most upvoted comments

Can you try it out and confirm?

Works for me as expected with and without v. Thank you!

rubo on Jul 16, 2023

This should be fixed in v6.6.4.

Can you try it out and confirm?

Thanks! 😃

ricmoo on Jul 16, 2023

There are two bugs currently.

yParity should be encoded as a hex string, not a number, in the JSON-RPC response. Some clients may encode it as a number (despite this being wrong) so it seems reasonable to accept either number or 0x${string} in ethers.
If a transaction is type 1 or 2, it should only have a yParity. If it has both a v and a yParity, the v should be ignored like any other extraneous unsupported parameter. If it has only a v and no yParity I would consider this an error, but if some existing clients do this you could try to interpret the v somehow. It strikes me as incorrect to simply call it yParity (expecting a value of 0 or 1), but such a client is already incorrect so it wouldn’t surprise me if it was doubly incorrect. I think if you wanted to be as absolutely defensive as possible you would convert 0 or 1 directly to yParity, and you would treat any other values as a legacy/155 transaction v and figure out what the y parity bit is and derive yParity from that.

If there are no clients that fail to include yParity in type 1/2 TransactionResponses then my recommendation is to not write and maintain all of the code to convert v to yParity as it would just be code that isn’t actually used and encourages future clients to misbehave.

MicahZoltu on Jul 13, 2023

@rubo Type 1 and type 2 transactions do not have a v value. they only have a yParity value. Including a v is incorrect behavior for anyone providing a signature for a type 1 or type 2 transaction.

If you are going to provide a v (against spec), then it should either be 27, 28, or yParity + CHAIN_ID * 2 + 35. 0 and 1 are never valid values of v for any transaction.

MicahZoltu on Jul 13, 2023