TBF, that large comment precedes 150 lines of arbitrary hex strings without even a variable name to tell them apart. I'm normally someone who prefers the code to speak to itself, rather than have a large prose comment - but if I came across that in a code review without an accompanying fifteen line comment I'd probably flag it as needing some explanation.

You have one comment for them. I think this is enough, unless you have no idea about what they're doing.

// Signatures with special case values for r and s (such as 0 and 1). // Such values often uncover implementation errors.

Of course! Code should be concise without being cleverly brief, and it should be clear with its intentions. I write software for business though that references back to requirements. In my case, I'm not explaining a bunch of odd values that look arbitrary. I'm indicating a reason for writing something the manner I'm which I wrote, so if it needs to be modified, they're not opening 5 tabs or searching through pages of documents to make sure things are still compatible. Or worse, modifying without caring and updating the test to assertNotNull(obj).

yeah - I try to encourage/force coworkers to remember that while `git blame` is a fantastic and useful thing, it only tells you what, not why.

It's the whys that cause the most head-scratching later, the whats are usually pretty straightforward (if not, it probably wouldn't make it through code review).