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).

#bitcoin

See github.com/Simplexum/python-bi

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.

Show thread

@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.

Follow

@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.

· · Web · 0 · 0 · 1
Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!