ethers.utils.splitSignature: recoveryParam doesn't match v value.

[Amxx]

ethers.utils.splitSignature("0x84708e867ef906fc61eecacf38218a209718e9529c32b33f5d68ee4c240b76133e3aeb2bacec6ae4b3fe0f9d982b214d265abe5434175dc41fc46210ff81a0da01")

returns

{ r:
   '0x84708e867ef906fc61eecacf38218a209718e9529c32b33f5d68ee4c240b7613',
  s:
   '0x3e3aeb2bacec6ae4b3fe0f9d982b214d265abe5434175dc41fc46210ff81a0da',
  _vs:
   '0x3e3aeb2bacec6ae4b3fe0f9d982b214d265abe5434175dc41fc46210ff81a0da',
  recoveryParam: 0,
  v: 28 }

I was expecting (for the most common cases where 27 <= v <= 28) to have v = 27 + recoveryParam

[ricmoo]

This is related to #893.

I've found the problem and am putting a fix in place.

It has to do with when a signature encodes the recoveryParam instead of a using the SIG header offset.

So, for signatures ending in 0 or 1, that is the recoveryParam and the canonical v is 27 + recoveryParam. For signatures ending with a value 27 or higher, take that as the v and compute the recoveryParam from the ((parity of v) xor 0x01). I was doing this step before normalizing the v, so the v was equal to the recoveryParam in this case.

It's harder to explain than show, once you see the code, I think the mistake will be more obvious. :)

[ricmoo]

This should be fixed in 5.0.5.

Try it out and let me know. :)

[ricmoo]

@Amxx Can you confirm this is still an issue? I know you continued having the problem after the fix, but just curious if it was a caching issue that has since gone away?

[ricmoo]

I think this is resolved now, so I'm going to close it. If you still have issues, please re-open.

Thanks! :)