Understanding ECDSA Point Validity and Malleability

Seems like this point checks out on secp256k1. What’s interesting is that for those two different points, they produce the same r-value because point coordinates are modulo p, while signatures are modulo n. Does this mean there are more malleability cases than just (r,s) and (r,-s)? Or could it lead to multiple public keys for the same signature?

I think any r-value above FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 isn’t valid in Bitcoin. But I get it now, it's more about theory than real life... technically could be considered malleable, but without knowing private keys, it’s not really an issue.

Yeah, you can get more than one public key from a valid ECDSA signature and a message. But that’s not about malleability since public keys are locked in the script. For instance, in a P2PKH script, the public key's hash is fixed in the scriptpub, and if you try a different key, the transaction gets rejected before signature verification.

Right, and according to BIP62, if s is over half of n, we just set s = n s. So, if s is too high, the signature is invalid. Theoretically, you could have 4 public keys for the same message and private key if r is less than n-p. This gives you two x-coordinates and two y-coordinates.

This is pretty much an academic chat. The chances of hitting any x mod n are so slim that splitting that probability in half doesn’t change the security much.

Not just academic! Check this out: 02FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 and 03FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 are like "zero" for r-value. So, if r=n, it simplifies the signature to s=z/k. This makes it valid, no matter what public key is used, depending on how it's implemented. Could lead to forks, too.