From EIP-2:
Allowing transactions with any s value with
0 < s < secp256k1n, as is currently the case, opens a transaction malleability concern, as one can take any transaction, flip the s value fromstosecp256k1n - s, flip the v value (27 -> 28,28 -> 27), and the resulting signature would still be valid.
Malleability was addressed by enforcing “low s”:
All transaction signatures whose s-value is greater than
secp256k1n/2are now considered invalid.
It seems that another way to fix this could have been to enforce v = 27. Then Ethereum signatures could be specified with 64 bytes (r,s) instead of 65 (v,r,s). Why didn’t we do that?