You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
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".
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
The text was updated successfully, but these errors were encountered: