ECDSA signatures are malleable. Given a valid signature (r, s), one can create a second valid signature by negating the s value.
I have searched workaround for this issue, and https://yondon.blog/2019/01/01/how-not-to-use-ecdsa says:
One solution to defend against signature malleability based attacks is to enforce a single canonical signature for a given public key and hash which is the approach taken by Bitcoin. More specifically, the Bitcoin core client software will only accept “low s-value” ECDSA signatures where a signature has a low s-value if s is less or equal to half the curve order [3]. The secp256k1 curve library used by the client will always generate signatures in low s-value form and the verifier expects provided signatures to also be in low s-value form [4].
Another solution is to avoid using signatures in identifiers or at the very least making sure to use unique values in the identifier creation process i.e. a nonce in the signed message. Unless there is a single canonical signature for a given public key and hash, signatures cannot be relied upon as unique identifiers.
What I wonder is, is it okay to use r-value instead of s-value for replay detection? One the first thought one should use s-value, because it is derived from a given message. r-value is not derived from a given message, but it uses k-value, which should be a random value. If duplicated k-values are used with same private key the key can be leaked, so signer have to generate distinct k-values. This makes me think r-value can be used to prevent replay attack.
Is there any problem if I use r-value to prevent replay attack?