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.
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).
@harding @pete yes, now you mention it, I do remember the reporting. thanks.
Back of the envelope it makes sense, we're talking on the order of 1% (2 bytes, maybe, out of 200, maybe). It sounds bigger when you say "a block a day" :) I think that is a very small win (I even remember vaguely thinking that at the time), but of course it doesn't mean my assessment of the effort vs the effect is correct.
Re: anti-fee sniping, yep agreed, I know Electrum and JM both match that, as well as c-lightning.
@waxwing With serialization, you can always get the benefits of variable-length by having a fixed-size format and compressing the zeros with a compression layer.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!