Are all these signatures cryptographically legitimate for a similar inputs? In that case, how can completely different implementations produce completely different signatures?
Sure. ECDSA as initially and formally outlined (like the sooner DSA utilizing Z_p it’s based mostly on) is randomized; see step 3 at https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm .
A tweak to make it deterministic, however nonetheless safe apart from leaking duplicates, was outlined subsequently in https://www.rfc-editor.org/data/rfc6979 . (For information, Thomas Pornin is a longtime and highranked contributor on https://crypto.stackexchange.com .) Signer implementations, together with these for bitcoin, could use this if the developer chooses; you will discover out by doing a number of signature operations on the identical information (or ‘consultant’ hash) and key with the identical implementation and seeing whether or not it repeats.
As well as, ECDSA signatures have the property that the “s” subject will be negated modulo the subgroup order n and each variations fulfill the verification equation. Years in the past this was utilized in some assaults, and consequently bitcoin now strongly prefers “low s” signatures — your 4 examples all do have “low s” (although that is not a big sufficient pattern to securely set up these implementations’ conformance with out taking a look at their internals or specs).
Is ECDSA signing deterministic internally, however the signature illustration permits for mathematical equivalence that produces completely different legitimate encodings?
No. Given a selected semantic signature (i.e. values of r and s), the DER encoding is exclusive. (So is the ‘plain’/P1363/PKCS11 encoding used for bitcoin message signatures versus transactions, and in another purposes like JWS.)
Would all these signatures be accepted by Bitcoin community nodes?
Sure, assuming you computed the hash as SHA256d over the right information.
