I recently learned that the typical use of libsecp contexts, in non-hot-path situations like during app startup of a heavyweight app, is just to give all the flags all the time.
I think it would be slightly helpful to document this by creating a SECP256K1_CONTEXT_ALL flag, and commenting it with a note on when it's appropriate to use (i.e. when a few dozen milliseconds aren't a big deal.)
CC: @apoelstra from earlier discussion
How should this work in a future where there are flags that turn on/off other behaviours and not just control what modes the libraries can be used in? e.g. I was considering a SECP256K1_NO_BIST to disable built in self-tests at context creation time.
Heh, I guess we could learn from the many other projects that used "all" for a set of flags which later turned out to be incomplete.
What if we created a flag SECP256K1_CONTEXT_DEFAULT which created both precomp tables and did the self-tests. Here "default" means "I have enough CPU and RAM that I don't need to think about it".
Yep and "default" should then also mean "I'm aware that this may need more CPU and RAM in the future but I know this will never break my current API calls in the future".
The context object doesn't really have flags anymore. From include/secp256k1.h:
* The only valid non-deprecated flag in recent library versions is
* SECP256K1_CONTEXT_NONE, which will create a context sufficient for all functionality
* offered by the library. All other (deprecated) flags will be treated as equivalent
* to the SECP256K1_CONTEXT_NONE flag.