Explain that ecrecover only accepts v={27,28}

[axic]

Two conditions have been implemented in clients:

1. The leading 31 bytes of the v value MUST be 0
2. For the last byte the values 27 and 28 are the only accepted ones

The first condition has been thoroughly tested (CALLCODEEcrecoverV_prefixedf0), the second one partially.

Client implementations:

• Geth: contracts.go crypto.go
• Erigon: contracts.go crypto.go
• Nethermind: EcRecoverPrecompile.cs
• ethereumjs: ecrecover.ts
• Besu: ECRECPrecompiledContract.java SECPSignature.java
• openethereum: builtin
• execution-specs: ececover.py
• revm/foundry: secp256k1.rs
• akula: precompiled.rs

[axic]

And finally this section doesn't mention that the precompile is not performing the check defined under (311).

@yperbasis how about adding another argument to ecdsarecover() for enabling that extra check? Would do it in a separate PR though.

[yperbasis]

And finally this section doesn't mention that the precompile is not performing the check defined under (311).

@yperbasis how about adding another argument to ecdsarecover() for enabling that extra check? Would do it in a separate PR though.

Instead of another argument to ecdsarecover() I'd add the checks to the precompile formula. But agree that it'd be better done in a separate PR. I can draft it after this one is merged.

[axic]

I can draft it after this one is merged.

Thanks! Probably would also move the h, v, r, s definitions after g_r.

[charles-cooper]

note for future reference: py-evm implementation here