EIP-2 Signature malleability: Why low s instead of dropping v?

[wjmelements]

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 from s to secp256k1n - 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/2 are 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?

[wjmelements]

A similar solution was proposed for ERC-2098: Compact Signature Representation. I think the approach I describe here is better because it is backward compatible with ecrecover.

[wjmelements]

Bitcoin made the same low s decision in BIP 146. Seems they also have a degree of freedom for r.

[wjmelements]

I made an ERC for low-v.

ERC-8111: Bound Signatures

Bound Signatures Bound signatures are ECDSA signatures bound to a specific v. Constraining the y-parity allows signatures to fit into 64 bytes. Background ECDSA signatures recover two public keys for the same hash. ECDSA signatures are recoverable when they indicate which of the public keys corresponds to the signing key. Previous developers signaled which using a y-parity bit. In Ethereum, this bit is encoded as v. ECDSA signatures (r, s) are malleable; the s can be reflected across n/2 (…