Bitcoin Forum

This point seems to be valid, and on secp256k1, as far as I know:
Also, for those two different points, we reach the same r-value, because point coordinates are calculated modulo "p", but signatures are calculated modulo "n":
Does it mean that when it comes to malleability, there are more cases than (r,s) and (r,-s), and that it is possible to alter it somehow? Or does it mean that for the same message, and the same signature, there is more than one matching public key?

Pretty sure any r that's above or equal to FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 is considered invalid by Bitcoin.

Nevermind, I misunderstood. I think technically it might be a malleability, but since I assume you don't know the actual private keys behind any of the public keys, it's more a theoretical issue than practical.

You can derive more than one possible public key from a valid ECDSA signature and message but that is not related to malleability since the public key is always locked in the script that is being spent one way or another (it is unchangeable).
For example in a P2PKH script the hash of the public key is already locked in the scriptpub and if you use a different public key the transaction will be rejected on OP_EQUALVERIFY before it even reaches the signature verification step.

P.S. All 3 public keys you posted are valid since they are on secp256k1 curve.

According to BIP62 (https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#user-content-Low_S_values_in_signatures), when the value of s is more than half of n (the total number of points), we simply take s = n - s. In other words, given this rule, any signature where the value of s is too high is considered invalid. As for public keys, there can theoretically be 4 different public keys for the same message and private key if the value of r is lower than n-p. In this case, you will have two x-coordinates (x=r and x=r+n) and two y-coordinates for each x (even and odd).

It is purely an academic discussion, as the probability of hitting any x mod n is already so low that dividing the probability by two won't make much of a difference in terms of security.