Fully static precomputation tables

real-or-random commented at 11:27 am on February 3, 2021: contributor

Currently we offer secp256k1_context_no_precomp [1] but it’s a “none” context.

If static precomputation (for ecmult_gen contexts) is enabled, we could easily offer a static secp256k1_context_sign. I believe we should do this and additionally offer static precomputation for ecmult contexts. This will make it possible to offer a static secp256k1_context_verify and a fully static secp256k1_context_sign_verify depending on the compilation flags.

I think this is very helpful for embedded targets and is probably much more convenient to use than the prealloc API [2], which requires to users to obtain the size of the context secp256k1_context_preallocated_size() at runtime and deal with manual allocation etc.

[1] Note that the docs can be improved here. They describe the context in terms of internals (“precomputed tables”). We should also describe this in terms of equivalent context flags. The same is true for the name of this thing. https://github.com/bitcoin-core/secp256k1/blob/8c727b9087ae012d5bb77e0766c21da763561a3c/include/secp256k1.h#L186-L191 [2] Also with behind language bindings #892, see also @gmaxwell’s comment there advocating for a fully static context

real-or-random cross-referenced this on Feb 3, 2021 from issue Performance issues on Wasm build by gregdhill

real-or-random commented at 6:22 pm on February 3, 2021: contributor

Fully static contexts would lose any ability to do randomization. The cost of creating a context that has a few bytes in it is extremely low– the thing that really ought to be static is the tables, everything else is quite cheap.

Indeed, I totally forgot about randomization. If we had static ecmult_gen tables and static ecmult tables, I think we can still make it easier for users to create contexts.

Some operations– e.g. batch operations – will always need scratch memory too.

Right but I don’t think they will need to belong to the context, and not everyone will need them.

I did not intend to advocate making the context some static variable– just making the expensive to compute tables static.

Yeah sorry, I noticed it when I read your comment again and should have edited my post here.

If a fully static context can be used then what is the point of having any context at all? – if it’s actually possible to eliminate the context it’s probably better to do that.

Hm, I guess not everyone has the same tradeoffs (code size, etc.), so if we get rid of contexts, we’ll lose some flexibility.

elichai cross-referenced this on Feb 15, 2021 from issue Add a global-context-less-secure feature which skips randomization by TheBlueMatt

elichai cross-referenced this on May 16, 2021 from issue Better lowmemory feature with precomputed ECMULT by devrandom

real-or-random commented at 4:06 pm on June 20, 2021: contributor

Related comment: #918 (comment)

real-or-random renamed this:
~~Fully static contexts~~
Fully static precomputation tables
on Jun 20, 2021

real-or-random cross-referenced this on Oct 8, 2021 from issue Make signing table fully static by real-or-random

real-or-random closed this on Dec 15, 2021

sipa cross-referenced this on Dec 29, 2021 from issue Signed-digit multi-comb ecmult_gen algorithm by sipa

Fully static precomputation tables #893