I’m testing ECDSA signature generation across multiple implementations for secp256k1 (CLightning, Decred, libsecp256k1, Bitcoin Core) and noticed they produce different but valid DER-encoded signatures for the same inputs.
Test Case:
- Private Key (hex):
0affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - Message Hash (hex):
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Results (hex):
- CLightning:
304402207b70993a3cdd981f140cae03fa0faf1d5890db5dc8af272e31df22ba1a86bc0b022011b35bf2ace986f6613657de85682b26faaa16818f0f0648805cc276ce82692d - Decred:
30440220716035ca9c33bfc3fd70fe7f89700abad953e8315ac01af725ae53be899e670b0220374b6b8ca8a5225ee3bbe7455b522ebb370b62765dbc1bdf07c7721d195163fa - libsecp256k1:
304502210090a1e3949628ede5c0b833c91f33013f2bf24cfe1bbc965b72606c71ef6747d50220061ef171914426471f4f5f060586774dba63b3b8e0f62d22777486a2f6ac31ea - Bitcoin Core:
304402201f9916f52ce48bed8cb03a1cb43e34eed656b7082a9672f2f3522a4f204b273802200798c61ee410d9947b73efbf5a0829244d5f68b8e9188ae05a3c9a227beda14c
My Questions:
-
Are all these signatures cryptographically valid for the same inputs? If so, how can different implementations produce different signatures?
-
Is ECDSA signing deterministic internally, but the signature representation allows for mathematical equivalence that produces different valid encodings?
-
Would all these signatures be accepted by Bitcoin network nodes?
