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.
@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.
You mention the fingerprinting risk, but at the time it was implemented, Bitcoin Core was also one of the only wallets using anti-fee-sniping, which is an even stronger fingerprint. Now there are a few other wallets doing that (including C-Lightning, which also low-R grinds).
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!