Further changes after making tables static #1065

1. 
   real-or-random commented at 6:13 PM on January 17, 2022: contributor

   More things to improve after #988:

   • Compile precomputation as a separate object file and link it (solved by #1042)
   • Speed up secp256k1_ecmult_gen_context_build at context creation. It currently computes fixed values which could be made static (open PR: #1120)
   • Document (or set by default) build options to remove unused static tables (and code) when no signing/verification function is called (something like --disable-shared CFLAGS="-fdata-sections -ffunction-sections -O2 -g" LDFLAGS="-Wl,--gc-sections")
   • Document the backwards-compatible API changes made in #988 and in #956: All contexts except the no_precomp context are now effectively signing contexts. The no_precomp context is effectively a verification context., and name is misleading as no context uses dynamic precompuation now. The reason why no_precomp is different is that it's impossible to re-randomize it.
   • Decide what to do with the no_precomp context: Possibilities include: renaming it, deprecating it (its main user rust-secp256k1 won't like this), and/or promote it a full signing context, maybe with a verbose name such as "global-context-less-secure" in the spirit of what rust-secp256k1 is doing.
2. 
   real-or-random commented at 12:14 PM on February 2, 2022: contributor

   * [ ]  Decide what to do with the `no_precomp` context: Possibilities include: renaming it, deprecating it (its main user rust-secp256k1 won't like this), and/or promote it a full signing context, maybe with a verbose name such as "global-context-less-secure" in the spirit of what rust-secp256k1 is doing.

   I suggest we

   • rename _no_precomp to _builtin (or similar)
   • keep a deprecated alias _no_precomp
   • expose the self-tests in the public API

   We should get rid of the "signing"/"verification" terminology. But there's potential for bikeshedding. We could also just call it secp256k1_context_builtin, or secp256k1_context_static, or secp256k1_context_basic which is generic enough that we'll never have to rename it again, even if we add cpuid/whatever in the future (see #780). A more verbose version will be _no_secret_ops. But ECDH is a secret op but we don't have blinding... And I don't mind that people are forced to at least have a glimpse at the docs.

   Does this sound good?

   As a next step, if desired, we could introduce a variant builtin_secret_ops_less_secure (or similar) which is a "signing" context that cannot be randomized... Not sure if we want this.

3. real-or-random renamed this:
   Futher changes after making tables static
   Further changes after making tables static
   on Feb 8, 2022
4. 
   jonasnick commented at 3:01 PM on February 22, 2022: contributor

   I suggest we

   • rename _no_precomp to _builtin (or similar)
   • keep a deprecated alias _no_precomp
   • expose the self-tests in the public API

   Concept ACK

   I'm not aware of the full scope of the context redesign discussions, but it seems like people find the no_precomp context useful. You mentioned the name secp256k1_context_static in PM, which I prefer over the mentioned alternatives.

5. real-or-random referenced this in commit 63a3565e97 on Jul 7, 2022
6. real-or-random added the label documentation on Jan 5, 2023
7. real-or-random added the label build on Jan 5, 2023
8. real-or-random added this to the milestone 0.3.1 (or 0.4.0) on Mar 8, 2023
9. real-or-random removed this from the milestone 0.3.1 (or 0.4.0) on Mar 8, 2023
10. real-or-random added this to the milestone stable release (1.0.0-rc.1) on Mar 8, 2023
11. 
    fametrano commented at 4:26 AM on October 15, 2026: contributor

    Is the open item here still wanted: documenting -ffunction-sections -fdata-sections with -Wl,--gc-sections, so that a static build drops the precomputed tables and code it never calls? If so, I'd open a short docs PR, with the binary size of a signing-only and a verification-only program measured both ways. Separately, after the May triage of milestone 1, are its five open issues all that is left before 1.0.0-rc.1?

12. 
    real-or-random commented at 7:11 AM on October 21, 2026: contributor

    Is the open item here still wanted: documenting -ffunction-sections -fdata-sections with -Wl,--gc-sections, so that a static build drops the precomputed tables and code it never calls? If so, I'd open a short docs PR, with the binary size of a signing-only and a verification-only program measured both ways.

    yes.

    Separately, after the May triage of milestone 1, are its five open issues all that is left before 1.0.0-rc.1?

    No. 1.0.0 is a separate discussion. If you ask me, there's no proper reason not to call the next release 1.0.0 except that we didn't do it in the past when there was also no proper reason.

Contributors

real-or-randomjonasnickfametrano

Milestone
stable release (1.0.0-rc.1)