Unless explicitly stated all pointer arguments must not be NULL.
The following rules specify the order of arguments in API calls:
- Context pointers go first, followed by output arguments, combined output/input arguments, and finally input-only arguments.
- Array lengths always immediately follow the argument whose length they describe, even if this violates rule 1.
- Within the OUT/OUTIN/IN groups, pointers to data that is typically generated later go first. This means: signatures, public nonces, secret nonces, messages, public keys, secret keys, tweaks.
- Arguments that are not data pointers go last, from more complex to less complex: function pointers, algorithm names, messages, void pointers, counts, flags, booleans.
- Opaque data pointers follow the function pointer they are to be passed to. Opaque data structure that holds context information
The primary purpose of context objects is to store randomization data for enhanced protection against side-channel leakage. This protection is only effective if the context is randomized after its creation. See secp256k1_context_create for creation of contexts and secp256k1_context_randomize for randomization.
A secondary purpose of context objects is to store pointers to callback functions that the library will call when certain error states arise. See secp256k1_context_set_error_callback as well as secp256k1_context_set_illegal_callback for details. Future library versions may use context objects for additional purposes.
A constructed context can safely be used from multiple threads simultaneously, but API calls that take a non-const pointer to a context need exclusive access to it. In particular this is the case for secp256k1_context_destroy, secp256k1_context_preallocated_destroy, and secp256k1_context_randomize.
Regarding randomization, either do it once at creation time (in which case you do not need any locking for the other calls), or use a read-write lock.
Definition at line 22 of file key.h.