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).
See https://github.com/Simplexum/python-bitcointx/commit/cf4a357e616db9e5a40b933095b1d2c331526024
Background:
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.
@waxwing Good argument for fixed length serializations...
@pete right, DER, sheesh, and let's not even get into ASN 1 in general , oh the horror ...
@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.
