API cleanup with respect to contexts

real-or-random commented at 12:05 pm on July 15, 2022: contributor

Documents the changes made to contexts that came with the transition to only static tables
Rename the static context
Expose the self tests for users of the static context

These are user-visible changes, so this is also a testbed for the changelog. I refrained from linking to the PR as the template proposed for multiple reasons:

Including the PR title is not in line with the suggestions in https://keepachangelog.com/en/1.0.0/ What they do instead is really just describe what parts in the API have changed, and I tend to agree that this is better for the user. The PR title can be rather technical or saying not too much, and a PR can correspond to multiple changes (for example this PR).
I’d be open to Include a link to the PR but I feel it’s a little bit annoying because you get the PR number only after creating the PR… Also I think the changelog is addressed to our users, not our devs. It should be just a log of user-visible changes (syntax and visible API behavior), so we anyway shouldn’t include every PR.

A normal strategy would be to create a release first, then make the API changes, but in this case, this would be somewhat confusing. The important thing here is the changes made to context flags and these are already for quite some time, so it makes sense to document these even for the initial release.

in include/secp256k1.h:199 in 0e32b29669 outdated

197  *  secp256k1_context_preallocated_create. */
198-#define SECP256K1_CONTEXT_VERIFY (SECP256K1_FLAGS_TYPE_CONTEXT | SECP256K1_FLAGS_BIT_CONTEXT_VERIFY)
199 #define SECP256K1_CONTEXT_SIGN (SECP256K1_FLAGS_TYPE_CONTEXT | SECP256K1_FLAGS_BIT_CONTEXT_SIGN)
200-#define SECP256K1_CONTEXT_DECLASSIFY (SECP256K1_FLAGS_TYPE_CONTEXT | SECP256K1_FLAGS_BIT_CONTEXT_DECLASSIFY)
201+
202+/** Deprecated context flags. These flags are treated equivalent to SECP256K1_CONTEXT_SIGN. */

real-or-random commented at 12:09 pm on July 15, 2022:

Unfortunately, it’s not possible to apply a deprecated attribute to a macro. We could turn this into a static const but this potentially breaks existing code. Maybe something to consider for the next API version.

apoelstra commented at 8:41 pm on July 15, 2022:

It would be easier for other language bindings if these were non-static consts … as either macros or statics they aren’t exported so we just have to reproduce the values in the target language.

apoelstra approved

apoelstra commented at 8:40 pm on July 15, 2022: contributor

ACK 0e32b29669d5df5de783dc115373eaf40539721d

apoelstra commented at 8:41 pm on July 15, 2022: contributor

Thanks for this! It’s super helpful that all the recent context changes are now visible in the docs.

in include/secp256k1.h:238 in 0e32b29669 outdated

230+ */
231+SECP256K1_API extern const secp256k1_context *secp256k1_context_static;
232+
233+/** Deprecated alias for secp256k1_context_no_precomp. */
234+SECP256K1_API extern const secp256k1_context *secp256k1_context_no_precomp
235+SECP256K1_DEPRECATED("Use secp256k1_context_static instead");

jonasnick commented at 1:55 pm on July 18, 2022:

There are still occurences of the deprecated no_precomp context in the code base.

real-or-random commented at 2:45 pm on July 18, 2022:

added a comment to address that

real-or-random commented at 10:36 pm on November 25, 2022:

fixed

in include/secp256k1.h:209 in 0e32b29669 outdated

199 #define SECP256K1_CONTEXT_SIGN (SECP256K1_FLAGS_TYPE_CONTEXT | SECP256K1_FLAGS_BIT_CONTEXT_SIGN)
200-#define SECP256K1_CONTEXT_DECLASSIFY (SECP256K1_FLAGS_TYPE_CONTEXT | SECP256K1_FLAGS_BIT_CONTEXT_DECLASSIFY)
201+
202+/** Deprecated context flags. These flags are treated equivalent to SECP256K1_CONTEXT_SIGN. */
203+#define SECP256K1_CONTEXT_VERIFY (SECP256K1_FLAGS_TYPE_CONTEXT | SECP256K1_FLAGS_BIT_CONTEXT_VERIFY)
204 #define SECP256K1_CONTEXT_NONE (SECP256K1_FLAGS_TYPE_CONTEXT)

jonasnick commented at 1:57 pm on July 18, 2022:

The examples still use the deprecated flags.

real-or-random commented at 10:36 pm on November 25, 2022:

fixed

jonasnick commented at 2:03 pm on July 18, 2022: contributor

Concept ACK

I refrained from linking to the PR

That’s reasonable. It should be possible to use git blame on the change log to find the exact code changes. Can you remove the change log template suggestion to add “Title with link to Pull Request”? Or just remove the template part entirely (starting with ## [MAJOR.MINOR.PATCH] - YYYY-MM-DD)?

real-or-random commented at 2:54 pm on July 18, 2022: contributor

Now that you mention the tests, I realize that many of the tests still use a lot of variants of the contexts, though we could simply check if all (non-static) contexts are equal (using memcpy). Let me add this.

But what about all the test code? What we currently have is not wrong, it’s just not efficient because we may run the same tests multiple tests. Should I simplify it? If yes, I don’t mind doing it here but it could also be done in a separate PR.

sipa commented at 3:00 pm on July 18, 2022: contributor

I find the explanation of context flags a bit confusing now.

The concept of “initialized for signing” still exists, and is referred to in API calls and the lack of it is mentioned for the static contexts, but at the same time, all flags that indicate verification/signing/… have lost their meaning. So what does “initialized for signing mean”? Is it just the static context that doesn’t have it, while all others do? Or is it somehow still linked to the flags passed at creation time, despite those being deprecated?

(just playing the devil’s advocate here, trying to show the reasoning someone going through the .h files may follow)

real-or-random commented at 3:37 pm on July 18, 2022: contributor

@sipa I agree. It will be probably confusing in particular for new users who don’t know the history. Do you have a suggestion? Call them “full context” and “static context” or similar?

sipa commented at 3:49 pm on July 18, 2022: contributor

@real-or-random Actually, in what way is the static context not usable for signing operations?

real-or-random commented at 4:31 pm on July 18, 2022: contributor

@real-or-random Actually, in what way is the static context not usable for signing operations?

Oh, we could make it usable for signing. (At the moment the relevant parts of the object are simply not initialized but that will be easy to fix, in particular now that #1120 has been merged.)

The actual question is whether we would like to make it usable for signing. The static context cannot be randomized, so you’ll never get protection by random blinding. I think allowing signing would not be unreasonable (and simplify the API and the docs a lot). But I’m not sure if we want to encourage this mode of usage. I tend to the opposite: Now that dynamic context creation is fast and doesn’t need a lot of memory, we should encourage people to use that route.

With the current API, you could argue that anyway a lot of users are probably never adding randomness, so it won’t make a lot of difference. But I think when evaluating this, we should keep in mind that a future context API will hopefully make it easier to randomize, e.g., context creation should directly accept a seed, and some of the (standard) signing API calls should rerandomize the context etc…

(This was one of the questions in #988 (comment), and there I decided to not change the API because we could always do it later.)

sipa commented at 6:05 pm on July 18, 2022: contributor

@real-or-random Hard question. On the one hand, yes, I think we do want to encourage using properly-(re)randomized signing contexts to get maximal blinding protection. But on the other hand, I also don’t think we should go as far as saying that one cannot use the signing API without forcing randomization; I could imagine platforms where randomness may actually be unavailable at signing time.

apoelstra commented at 7:03 pm on July 18, 2022: contributor

In particular, in rust-wasm it is very difficult to get randomness (there are definitely ways to get randomness in JS but for some reason these are not exposed in WASM and the standard Rust randomness crate will not work).

real-or-random commented at 7:49 am on July 19, 2022: contributor

On the one hand, yes, I think we do want to encourage using properly-(re)randomized signing contexts to get maximal blinding protection. But on the other hand, I also don’t think we should go as far as saying that one cannot use the signing API without forcing randomization;

Okay, then the current API does exactly this. You are not forced to call context_randomize but you don’t get a convenience bonus from the static context.

edit: I can try to rewrite this with better names and make sure the static context is a special case. Then some of the function descriptions would they’re not compatible with the static context; I’m sure there’s a brief way to say this.

sipa commented at 6:30 pm on July 19, 2022: contributor

I feel it would be simpler to do make the static context usable for signing functions, and then remove the “initialized for signing” and “initialized for verification” conditions in the API documentation everywhere.

Even if we don’t do that, the notion of “initialized for verification” is not defined anywhere anymore, and not relevant, so that seems like it should certainly disappear.

jonasnick commented at 9:04 pm on July 19, 2022: contributor

I don’t think “initialized for signing” is very confusing (it would be clearer if the flag was explicitly mentioned). The flag is not deprecated after all. Also the static context explicitly mentions that it’s not initialized for signing. However, if it’s not too complicated to implement, sipa’s approach (which involves deprecating the signing flag?) seems to be a significant simplification of the initial release API.

real-or-random commented at 10:03 pm on July 19, 2022: contributor

Even if we don’t do that, the notion of “initialized for verification” is not defined anywhere anymore, and not relevant, so that seems like it should certainly disappear.

The PR (even in its current form) already removes all “initialized for verification”. Or are you saying I missed some?

However, if it’s not too complicated to implement, sipa’s approach (which involves deprecating the signing flag?) seems to be a significant simplification of the initial release API.

Making the static context usable for signing will be rather simply to implement under the hood. And I don’t think this change to the static context would affect the context creation flags. Even with the current PR, the flags are simply ignored. As all contexts behave like the SIGN flag did in the past, I’d still say that the right way to document this is to deprecate all flags expect SIGN. @jonasnick What’s your opinion on encouraging randomization vs keeping the API simple?

sipa commented at 10:39 pm on July 19, 2022: contributor

The PR (even in its current form) already removes all “initialized for verification”. Or are you saying I missed some?

I’m confused why I said that. I must have been looking at the wrong branch… Please disregard.

jonasnick commented at 12:47 pm on July 20, 2022: contributor

@real-or-random

As all contexts behave like the SIGN flag did in the past, I’d still say that the right way to document this is to deprecate all flags expect SIGN.

When I pondered whether sipa’s approach would involve deprecating SIGN I had thought that the SIGN flag is still necessary for signing. But that’s not the case. So there’s only a minor reason to deprecate SIGN:

With your current PR, the only reason the SIGN flag exists is to distinguish between static and dynamic contexts as far as I can see. If we allow signing with static contexts, the SIGN flag lost its meaning entirely since all contexts are SIGN contexts. Therefore, we could deprecate all flags except NONE, which would be the default flag that we’d most likely choose if we started with a clean slate. But effectively it’s just a different name.

What’s your opinion on encouraging randomization vs keeping the API simple?

I’m slightly in favor of allowing secret key operations with the static context, because it allows removing the “initialized for signing” terminology which is somewhat confusing.

sipa commented at 2:08 pm on July 20, 2022: contributor

With your current PR, the only reason the SIGN flag exists is to distinguish between static and dynamic contexts as far as I can see.

Not even. There is no way to construct a context which doesn’t have signing capability. It’s just that there is one special context precreated which cannot. That doesn’t need a notion of a signing flag, just an exception (“this context can’t be used for signing operations”). Referring to that as “initialized for signing” is confusing to me, as it makes it sound like there is some step (“initialization”) the user has to do which is missing. It’s more a capability than initialization.

real-or-random commented at 2:16 pm on July 20, 2022: contributor

I’m still slightly in favor of the more conservative option that keeps the semantics as is but I think it could be convinced otherwise.

Referring to that as “initialized for signing” is confusing to me, as it makes it sound like there is some step (“initialization”) the user has to do which is missing. It’s more a capability than initialization.

Indeed. I just talked to Jonas somewhere else and I decided to give rewriting the docs a try. So I’ll update the PR to avoid the “init” terminology and then we can see if we like it or if we want to get rid of the distinction between static/dynamic entirely.

jonasnick cross-referenced this on Jul 31, 2022 from issue Enable non-experimental modules by default by real-or-random

jonasnick added this to the milestone initial release (0.x) on Jul 31, 2022

real-or-random marked this as a draft on Aug 3, 2022

real-or-random commented at 7:10 pm on August 3, 2022: contributor

I added some WIP commits to demonstrate how another version would look like. This now tries to avoid the “historical” terminology entirely. As a consequence, this also introduces the new flag SECP256K1_CONTEXT_DEFAULT (name inspired by #559 and up to bikeshedding of course).

WIP because

the actual flags are not yet updated
this does not touch all occurrences of “initialized for signing”
and this will need some paragraph formatting.
examples need to be updated

I can take care of all of this once know which version we want to have.

Please have a look and tell me if you prefer this new version (maybe with some changes) or instead allowing secret key ops with the static context. I still lean towards disallowing secret key ops with the static context because allowing it would create an incentive to skip randomization:

On the one hand, yes, I think we do want to encourage using properly-(re)randomized signing contexts to get maximal blinding protection. But on the other hand, I also don’t think we should go as far as saying that one cannot use the signing API without forcing randomization;

Okay, then the current API does exactly this. You are not forced to call context_randomize but you don’t get a convenience bonus from the static context.

jonasnick commented at 12:47 pm on August 10, 2022: contributor

I think your WIP commits are an improvement over the previous version. Regarding the exact wording, if we’d add a new function that operates on secret keys and requires a new context flag, would we document it as

0 *  Args:    ctx:       pointer to a context object, configured with flag SECP256K1_CONTEXT_FOO (not secp256k1_context_static).

?

real-or-random commented at 1:35 pm on August 10, 2022: contributor

0 *  Args:    ctx:       pointer to a context object, configured with flag SECP256K1_CONTEXT_FOO (not secp256k1_context_static).

Yeah, that’s roughly what I had in mind. Maybe s/configured/created/

real-or-random commented at 3:25 pm on August 29, 2022: contributor

Note: This approach got Concept ACKed at the IRC meeting two weeks ago, so it’s currently up to me to unWIP the PR.

real-or-random cross-referenced this on Aug 29, 2022 from issue Uncompressed Bulletproof Rangeproofs by apoelstra

real-or-random force-pushed on Nov 25, 2022

docs: Never require a verification context ee7341fbac

docs: Change signature "validation" to "verification" 1a553ee8be

real-or-random force-pushed on Nov 25, 2022

real-or-random marked this as ready for review on Nov 25, 2022

real-or-random force-pushed on Nov 25, 2022

real-or-random commented at 10:32 pm on November 25, 2022: contributor

Ready for review.

This probably could have been split into multiple PRs in hindsight but I think it’s still manageable.

One open question (that can be resolved after this PR) is whether and how we want to tidy the tests… At the moment they still use deprecated flags like SECP256K1_CONTEXT_NONE.

real-or-random force-pushed on Nov 25, 2022

in include/secp256k1.h:839 in 332fc7d45e outdated

853+ * side-channel observations which aim to exploit secret-dependent behaviour in
854+ * certain computations which involve secret keys.
855+ *
856+ * It is highly recommended to call this function on contexts created using
857+ * secp256k1_context_create or secp256k1_context_clone (as well as
858+ * secp256k1_context_preallocated_create or secp256k1_context_clone, resp.)

jonasnick commented at 1:53 pm on November 28, 2022:

secp256k1_context_preallocated_clone?

real-or-random commented at 10:44 am on November 29, 2022:

fixed by rephrasing

in include/secp256k1.h:238 in 332fc7d45e outdated

239+ */
240+SECP256K1_API extern const secp256k1_context *secp256k1_context_static;
241+
242+/** Deprecated alias for secp256k1_context_no_precomp. */
243+SECP256K1_API extern const secp256k1_context *secp256k1_context_no_precomp
244+SECP256K1_DEPRECATED("Use secp256k1_context_static instead");

jonasnick commented at 2:32 pm on November 28, 2022:

Isn’t this a “deprecated alias for secp256k1_context_static”?

real-or-random commented at 10:44 am on November 29, 2022:

fixed

in include/secp256k1.h:850 in 332fc7d45e outdated

867+ * kind are performed by exactly those API functions which are documented to
868+ * require a context that is not the secp256k1_context_static. As a rule of thumb,
869+ * these are all functions which take a secret key (or a keypair) as an input.
870+ * A notable exception to that rule is the ECDH module, which relies on a different
871+ * kind of elliptic curve point multiplication and thus does not benefit from
872+ * enhanced protection against side-channel leakage currently.

jonasnick commented at 2:54 pm on November 28, 2022:

nit: Wouldn’t the remark that ECDH does not benefit from enhanced protection belong to the ECDH doc? Or is this paragraph intended to calrify the “computations involving secret keys” after which it makes sense to rerandomize?

real-or-random commented at 10:33 am on November 29, 2022:

The pragmatic reason why I added this paragraph is to make sure we’re not conveying the wrong impression that ECDH is protected. Without this paragraph, you’d probably think that ECDH is protected (because secret keys are involved.)

So this violates the module separation but I also think the context (and its docs) is somehow global and independent of the modules in some sense.

Or is this paragraph intended to calrify the “computations involving secret keys” after which it makes sense to rerandomize?

That’s another purpose, yes.

jonasnick commented at 10:19 pm on November 28, 2022: contributor

ACK mod nits

As part of the review I created a branch that removes the deprecated flags from the tests & benchmarks. I can open a PR after this one is merged.

Can you remove the change log template suggestion to add “Title with link to Pull Request”? Or just remove the template part entirely (starting with ## [MAJOR.MINOR.PATCH] - YYYY-MM-DD)?

I can do this when I rebase #1055.

real-or-random force-pushed on Nov 29, 2022

jonasnick commented at 4:21 pm on November 29, 2022: contributor

ACK 92e7293d6129e73ecd1226e6f30930ace4f569de

apoelstra approved

apoelstra commented at 7:21 pm on November 29, 2022: contributor

utACK 92e7293d6129e73ecd1226e6f30930ace4f569de

in include/secp256k1.h:852 in 2e9335a68c outdated

868+ * these are all functions which take a secret key (or a keypair) as an input.
869+ * A notable exception to that rule is the ECDH module, which relies on a different
870+ * kind of elliptic curve point multiplication and thus does not benefit from
871+ * enhanced protection against side-channel leakage currently.
872+ *
873+ * It is safe call this function on a copy of secp256k1_context_static in writable

sipa commented at 0:19 am on November 30, 2022:

Typo: it is safe to call this function.

sipa commented at 6:35 pm on December 5, 2022:

Still todo (it is safe to call this function)

in include/secp256k1.h:639 in 1fe4142c60 outdated

637@@ -638,7 +638,7 @@ SECP256K1_API extern const secp256k1_nonce_function secp256k1_nonce_function_def
638  *
639  *  Returns: 1: signature created
640  *           0: the nonce generation function failed, or the secret key was invalid.
641- *  Args:    ctx:       pointer to a context object, initialized for signing.
642+ *  Args:    ctx:       pointer to a context object (not secp256k1_context_static).

sipa commented at 0:20 am on November 30, 2022:

Should this (and elsewhere) say (not secp256k1_context_static and clones thereof)?

real-or-random commented at 9:13 am on November 30, 2022:

Strictly speaking yes. I omitted this because it’s perhaps obvious, it adds clutter everywhere, and confuses the user more than it helps: cloning the static context is a pretty obscure operation. (Is there any valid use case even?) I think we could in fact disallow this operation. I doubt this hurts anyone, and it would arguably make the API docs even simpler. But I didn’t add this to this PR because it would technically be a backward incompatible change, and its of limited use: We cannot prevent the user from simply copying the memory, e.g., using memcpy.

Now that you bring this up, what we could do is to add a further comment to the docs of _context_clone or the docs of the static context? I think would be the best way to document that the restrictions apply also to clones. Do you want me to do this?

sipa commented at 5:32 pm on November 30, 2022:

I mostly asked to make sure I understood.

Just pointing out that the static context can’t be cloned should be sufficient.

real-or-random commented at 9:14 am on December 1, 2022:

Just pointing out that the static context can’t be cloned should be sufficient.

“pointing out that the static context can’t be cloned” would mean forbidding it. Or do you mean “pointing out that it should not be cloned”?

sipa commented at 3:52 pm on December 2, 2022:

I think for now it’s better to just outlaw cloning the static context, as I think there is no point? You can achieve exactly the same functionality (and more) by instead creating a new context. Nor do I think there is any user currently relying on such a weird feature.

If there is ever a point in supporting it, it’s easier to make it supported later than the other way around, once we stabilize the API.

real-or-random commented at 2:07 pm on December 5, 2022:

I think for now it’s better to just outlaw cloning the static context, as I think there is no point?

Agreed. I’m in the middle of doing this but it’s a small mess and it should not hold up this PR. I’ll open a follow up PR on top of this..

apoelstra referenced this in commit 082c3bdd1c on Nov 30, 2022

real-or-random cross-referenced this on Dec 1, 2022 from issue PROTOTYPE Split headers to make it possible to use only prealloc API by real-or-random

jonasnick cross-referenced this on Dec 1, 2022 from issue Replace deprecated context flags with NONE in benchmarks and tests by jonasnick

real-or-random commented at 9:27 am on December 2, 2022: contributor

Here’s something that came up when reviewing #1168, where @jonasnick changes the tests to use secp256k1_context_create(SECP256K1_CONTEXT_DECLASSIFY)

I was wondering if this should be SECP256K1_CONTEXT_DEFAULT | SECP256K1_CONTEXT_DECLASSIFY? I mean… it won’t matter for the tests. But assume we’ll add a new flag SECP256K1_CONTEXT_FANCY_FEATURE?

So far, the flags have really been bitflags, so that you can bitwise-OR them. And so far, SECP256K1_CONTEXT_NONE has been the neutral element in this algebraic group.

After this PR, if you want fancy features, should you ask for SECP256K1_CONTEXT_DEFAULT | SECP256K1_CONTEXT_FANCY_FEATURE? Or just SECP256K1_CONTEXT_FANCY_FEATURE (which has a different value since SECP256K1_CONTEXT_DEFAULT != SECP256K1_FLAGS_TYPE_CONTEXT – the “SIGN bit” (1 << 9) is set).

I think in the end it won’t really matter – as long as we promise to ignore the value of the “SIGN bit”.

But I wonder:

Should DEFAULT in fact be an alias to (the existing value of) NONE? I didn’t do that due to ABI compatibility: If the user has a new header but an old binary, then they’ll get an actual NONE context… I’m not sure if this matters at all but making DEFAULT an alias to SIGN seems slightly cleaner.
Does “DEFAULT” make sufficiently clear that it is supposed to be the neutral element of a group (which it is if we’ll ignore the value of the SIGN bit)? Maybe NONE expressed this better, and now I realize that @jonasnick suggested this above: “Therefore, we could deprecate all flags except NONE, which would be the default flag that we’d most likely choose if we started with a clean slate. But effectively it’s just a different name.”

So now that I’ve been writing this, I think slightly cleaner solution will be to

set the SIGN bit with value 1 as part of SECP256K1_FLAGS_TYPE_CONTEXT instead (just to ensure the mentioned ABI compatibility)
call the one non-deprecated flag NONE (instead of DEFAULT) and set no “feature” bits at all.

This is indeed a new clean slate. And it reserves the DEFAULT name flag for future use. (Maybe in the future, we want introduce a feature that should be enabled by “default”, and we could rather use “DEFAULT” to mean “give me whatever the maintainers think should be the default” instead of “enable no features”.)

Opinions? I’ll think I’ll make that change this if noone objects.

jonasnick commented at 2:56 pm on December 2, 2022: contributor

I’d be in favor of calling the non-deprecated flag NONE and keep it being the neutral element wrt | as you’re suggesting. When I wrote the code you reference I had to stop for a moment and asked myself the exact question that you mentioned.

contexts: Deprecate all context flags except SECP256K1_CONTEXT_NONE 316ac7625a

docs: Improve docs for static context 72fedf8a6c

contexts: Rename static context 53796d2b24

tests: Use new name of static context d2c6d48de3

selftest: Rename internal function to make name available for API e383fbfa66

selftest: Expose in public API e02d6862bd

docs: Tidy and improve docs about contexts and randomization 06126364ad

docs: Get rid of "initialized for signing" terminology e7d0185c90

docs: Use doxygen style if and only if comment is user-facing

and improve phrasing slightly.

7289b51d31

examples: Switch to NONE contexts 4386a2306c

real-or-random force-pushed on Dec 5, 2022

real-or-random commented at 2:10 pm on December 5, 2022: contributor

Ok, I changed the _DEFAULT back to _NONE. But after talking to @jonasnick , I realized that I don’t need to fiddle with SECP256K1_FLAGS_TYPE_CONTEXT. The behavior before this PR was perfectly fine, it’s simply not properly documented. So the only thing that this PR now does (with respect to context flags) is to fix the docs.

jonasnick commented at 2:11 pm on December 5, 2022: contributor

ACK 4386a2306c2b8cf9ad3040d8010e4295f6f01490

sipa commented at 6:42 pm on December 5, 2022: contributor

utACK 4386a2306c2b8cf9ad3040d8010e4295f6f01490

There’s a typo left, but if this is going to need a follow-up anyway, that can be done then too.

jonasnick merged this on Dec 6, 2022

jonasnick closed this on Dec 6, 2022

real-or-random referenced this in commit 5c789dcd73 on Dec 7, 2022

real-or-random cross-referenced this on Dec 7, 2022 from issue contexts: Forbid destroying, cloning and randomizing the static context by real-or-random

real-or-random cross-referenced this on Dec 7, 2022 from issue Fix backport of bitcoin-core/secp256k1#925 (drop 'include/' prefix from -I) by mattiaferrari02

apoelstra cross-referenced this on Dec 8, 2022 from issue Fully describe safety requirements by tcharding

real-or-random cross-referenced this on Dec 8, 2022 from issue Change ARG_CHECK_NO_RETURN to ARG_CHECK_VOID which returns (void) by real-or-random

sipa referenced this in commit 9d47e7b71b on Dec 13, 2022

dhruv referenced this in commit 55ffd47cc6 on Dec 14, 2022

dhruv referenced this in commit 967c65b158 on Dec 14, 2022

dhruv referenced this in commit 78b5ddf28b on Jan 11, 2023

dhruv referenced this in commit 215394a1d5 on Jan 11, 2023

sipa referenced this in commit 5fbff5d348 on Jan 19, 2023

div72 referenced this in commit 945b094575 on Mar 14, 2023

str4d referenced this in commit 0df7b459f6 on Apr 21, 2023

vmta referenced this in commit e1120c94a1 on Jun 4, 2023

vmta referenced this in commit 8f03457eed on Jul 1, 2023

jonasnick cross-referenced this on Jul 18, 2023 from issue Upstream PRs 993, 1152, 1165, 1126, 1168, 1173, 1055 by jonasnick

API cleanup with respect to contexts #1126