Dmitry Petukhov has implemented low-R grinding in python-bitcointx 1.1.2dev (not in a release yet), and this behaviour would align it with Core.
(What's "low-R grinding"? The nonce can be anything in an ECDSA signature, so we would like to shave off a byte if we can by making the EC point "R" be smaller than half the max (DER's exotic behaviour plays in here); though the nonce generation is deterministic, space for extra randomness is allowed in RFC6979, see section 3.6).
ECDSA sigs are (R, s), R is an EC point, s is a scalar.
R has for a long time by most libraries been generated "deterministically" (to avoid f-ups in sourcing randomness), by doing a very fancy version of "hash the message and the private key", that fancy version is called RFC6979. low-R grinding can make it a tiny bit smaller, on average.
If different wallets do/do not grind, that's a potential fingerprint.
@pete fwiw i didn't read the discussions at the time, but i probably would have been a NACK on this in Core, i don't see the point of adding such code for (on average) less than one byte's difference. I'd be curious why my assessment is wrong, there.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!