BIP Draft: Low-R Grinding for ECDSA Signatures

[liamgilligan]

Informational BIP describing low-R grinding: re-deriving the ECDSA nonce under a counter until r has its high bit unset, so the DER encoding needs no leading null byte.

This was discussed on the mailing list: https://groups.google.com/g/bitcoindev/c/boEZRlqczvw

Reference implementation and test vectors are TODO.

Feedback is very welcome.

[jonatack]

For reviewers, see also discussion in bitcoinj/secp256k1-jdk#419 and the following posts by @Sjors (ordered by date inc) in the relevant Bitcoin Core PR:

• Always create signatures with Low R values bitcoin#13666 (comment)
• Always create signatures with Low R values bitcoin#13666 (comment)
• Always create signatures with Low R values bitcoin#13666 (comment)

[murchandamus]

Thanks, adding this to my to-read list.

[craigraw]

Another important motivation is that signatures produced according to a standardised approach will be byte-identical. This means signers can be compared to ensure they are not leaking secrets by embedding them in signatures (e.g. Dark Skippy).

[murchandamus]

Looks very good. I just have a couple nits for you.

[murchandamus]

The document should have a Rationale section. The Rationale should describe design decisions, compare to potential alternate designs and related work. You could mention the suggestion that Craig gave there. The explanation why incrementing a counter on top of RFC6979 is safe and recommend could also be located in that section. Some of the Footnotes would fit there as well, in fact, many BIPs use the Footnotes section as the Rationale.

[jeanpablojp]

Since the reference implementation and test vectors are still marked TODO, I'd like to offer help there, if you aren't already deep into them.

What I have in mind is an independent Python implementation of the recommended instantiation: pure Python secp256k1, RFC 6979 with the grind counter in the additional data, the grinding loop, and DER encoding, plus a script that generates the vectors and a separate one that verifies them, everything checked byte for byte against Bitcoin Core's signer. I built the spend-path vectors for the BIP 360 draft recently (#2232), so this is familiar ground.

The reason I think an implementation that shares no code with libsecp is worth having: if it agrees with Core on the vectors, that's good evidence the text is unambiguous, and if it doesn't, the first diverging intermediate value shows exactly which part needs tightening.

If that sounds useful, two things worth deciding up front:

1. Should the vectors carry intermediate values (additional data, nonce, r, s before low-s normalization, final DER), or only key, message hash, counter and signature? My preference is the full set: the keys are test-only so there's nothing to protect, and the intermediates are what lets two implementations find where they diverge. RFC 6979 publishes k in its own vectors.
2. A JSON file next to the document, or vectors inline in the markdown?

Happy to open the result as a PR against your branch, or just post it here, whichever works better for you.

[liamgilligan]

@jeanpablojp I appreciate the offer, but I've already written a test implementation, and waiting to push it until I resolve everything in the text. Once it is pushed, I would really appreciate a review of the code, if you have time.

[jeanpablojp]

Will do, happy to review it when it's up.

[liamgilligan]

@murchandamus made the changes you recommended. However, I'm wondering whether or not this BIP should be classified as "Informational". With the addition of the Rationale section, the BIP seems split across how Low-R Grinding can be done and how it should be done. Of course, a signer need not follow Core's implementation in order to produce low-r signatures, but BIP-3 does say the "distinguishing characteristic of a Specification BIP is that it can be implemented, and implementations can be compliant with it". What do you think?

[murchandamus]

I’m open to the idea to make it a Specification BIP, but in that case, you should specify one concrete approach. :)

[liamgilligan]

@murchandamus made the changes you requested and turned it into a specification BIP, and included the pseudocode.