vague error when the private key passed to the addr cheatcode is greater than the secp256k1 curve order

[odyslam]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (20e7386 2022-08-31T00:09:48.876171Z)

What command(s) is the bug in?

forge test

Operating System

macOS (Apple Silicon)

Describe the bug

Same as #2158

Perhaps it would be nice to bake something in forge or forge-std so the user doesn't have to do

vm.assume( privKey != 0 && privKey < 115792089237316195423570985008687907852837564279074904382605163141518161494337)
``` all the time. I imagine that it's a fairly common use case

[mds1]

What error message do you see? It should be [FAIL. Reason: Private key must be less than 115792089237316195423570985008687907852837564279074904382605163141518161494337 (the secp256k1 curve order). which I think is pretty descriptive. More info here: #2164 (comment)

Instead of assume you can also use uint248 as the input type for the private key: this obviously shrinks the range of private keys you'll get since type(uint248).max < curve order, but it should be good enough for most use cases. Though that'll still revert on zero, so using bound is another option

[odyslam]

I see the error described in #2158

Interesting. I assumed it's best practice to use assume over bound.

[mds1]

Ok I see:

• Passing in the curve order exactly results in signature error
• Passing anything 1 greater than curve order results in the expected error message

Should be an easy fix, I'll get a PR in.

Re assume vs. bound, the assume condition here is broad enough that assume should be fine. For "narrow" conditions, you might get a lot of rejects and bound of course would have zero rejects so would result in a faster test suite. "Broad" and "tight" are grey, there's no hard rule here and definitely some personal preference involved.