Are all these signatures cryptographically valid for the same inputs? If so, how can different implementations produce different signatures?
Yes. ECDSA as originally and officially defined (like the earlier DSA using Z_p it is based on) is randomized; see step 3 at https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm .
A tweak to make it deterministic, but still secure except for leaking duplicates, was defined subsequently in https://www.rfc-editor.org/info/rfc6979 . (For info, Thomas Pornin is a longtime and highranked contributor on https://crypto.stackexchange.com .) Signer implementations, including those for bitcoin, may use this if the developer chooses; you can find out by doing multiple signature operations on the same data (or ‘representative’ hash) and key with the same implementation and seeing whether it repeats.
In addition, ECDSA signatures have the property that the “s” field can be negated modulo the subgroup order n and both versions satisfy the verification equation. Years ago this was used in some attacks, and as a result bitcoin now strongly prefers “low s” signatures — your 4 examples all do have “low s” (though that’s not a large enough sample to safely establish those implementations’ conformance without looking at their internals or specifications).
Is ECDSA signing deterministic internally, but the signature representation allows for mathematical equivalence that produces different valid encodings?
No. Given a particular semantic signature (i.e. values of r and s), the DER encoding is unique. (So is the ‘plain’/P1363/PKCS11 encoding used for bitcoin message signatures as opposed to transactions, and in some other applications like JWS.)
Would all these signatures be accepted by Bitcoin network nodes?
Yes, assuming you computed the hash as SHA256d over the correct data.
