variable sized precomputed table for signing #337

douglasbakkum · 2015-10-18T10:04:49Z

This pull request gives an option to reduce the precomputed table size for the signing context (ctx) by setting #define ECMULT_GEN_PREC_BITS [N_BITS].

Motivation: Per #251 and #254, the static table can be reduced to 64kB. However, this is still too big for some of my embedded applications. Setting #define ECMULT_GEN_PREC_BITS 2 produces a 32kB table at a tradeoff of about 75% of the signing speed. Not defining this value will default to the existing implementation of 4 bits. Statistics:

ECMULT_GEN_PREC_BITS = 1
Precomputed table size: 32kB
./bench_sign 
ecdsa_sign: min 195us / avg 200us / max 212us

ECMULT_GEN_PREC_BITS = 2
Precomputed table size: 32kB
./bench_sign 
ecdsa_sign: min 119us / avg 126us / max 134us

ECMULT_GEN_PREC_BITS = 4 (default)
Precomputed table size: 64kB
./bench_sign
ecdsa_sign: min 83.5us / avg 89.6us / max 95.3us

ECMULT_GEN_PREC_BITS = 8
Precomputed table size: 512kB
./bench_sign 
ecdsa_sign: min 96.4us / avg 99.4us / max 104us

Only values of 2 and 4 make sense. 8 bits causes a larger table size with no increase in speed. 1 bit runs, actually, but does not reduce table size and is slower than 2 bits.

douglasbakkum · 2015-10-18T10:35:59Z

See also comments about alternatively using wNAF:
#189 (comment)

gmaxwell · 2015-10-18T16:27:14Z

Reasonable enough.

Can you help me understand your memory trade-off requirements? There is a way to halve the table size without largely changing the performance though it requires getting rid of the nums blinding. I'd been under the impression that with the table completely static most of the reasonable target embedded devices (e.g. arm m3s with 192k ram) would end up with the table in their relatively copious flash and there was no real need to reduce below 64k on them.

douglasbakkum · 2015-10-18T17:33:10Z

Sure. The current device has 256kB of flash and 64kB of RAM on a Cortex M4. The secp256k1 library (including the 64kB table) takes up about 140kB in total.

jonasschnelli · 2015-10-18T18:03:09Z

Concept ACK.
I think hardware wallets and other use-cases on embedded devices don't really seek for super-performance. But they like to use a reliable and well-testes library that fits on a chip with tiny ram and tiny flash. Removing precomputed tables sounds after a logical tradeoff in that territory.

ddustin · 2018-10-23T19:44:51Z

Is there a reason this was never merged in?

gmaxwell · 2019-05-23T00:31:29Z

@real-or-random This complements the WINDOW_G work, would you mind reviewing it?

real-or-random · 2019-05-23T08:57:55Z

I'll have a look. :)

real-or-random · 2019-05-24T07:57:47Z

src/ecmult_gen_impl.h

@@ -49,39 +49,39 @@ static void secp256k1_ecmult_gen_context_build(secp256k1_ecmult_gen_context *ctx

    /* compute prec. */
    {
-        secp256k1_gej precj[1024]; /* Jacobian versions of prec. */
+        secp256k1_gej precj[ECMULT_GEN_PREC_N * ECMULT_GEN_PREC_G]; /* Jacobian versions of prec. */
        secp256k1_gej gbase;
        secp256k1_gej numsbase;
        gbase = gj; /* 16^j * G */


there are some comments that should be changed here and up to line 67

I updated the comments, assuming you meant to change, for example, 16 to PREC_G. Let me know if there is something in addition.

real-or-random · 2019-05-24T08:04:56Z

@douglasbakkum I know this is very old. Are you still interested in this PR? If yes, it needs rebase. If not, we could adopt it.

douglasbakkum · 2019-05-24T09:29:03Z

Awesome. Yes definitely interested. We have been using this in production BitBox's since the PR was submitted.

I will rebase.

douglasbakkum · 2019-05-24T10:22:08Z

@real-or-random The PR is now rebased. Let me know if you would like further changes.

real-or-random · 2019-05-24T11:52:17Z

Thanks, looks good to me!

What we need to do is make this and #596 consistent (for naming of constants, ./configure, etc.) I think the easiest way forward is to get #596 merged and then adapt this PR here. (I know this is also the easiest way for me as the author of #596 but I'm of course open to other suggestions too. :P)

@gmaxwell What do you think? I'm not convinced that "window size" would be an appropriate term here, so maybe PREC_BITS makes more sense in general?

gmaxwell · 2019-05-25T10:12:02Z

Sounds fine to me (both on the sequence and the naming)

gmaxwell · 2019-05-29T12:08:39Z

#596 is now merged and I don't believe there is anything at risk of imminent merger which will cause difficult conflicts with this PR.

gmaxwell · 2019-05-29T20:47:13Z

@real-or-random ^

real-or-random · 2019-05-30T11:40:54Z

Great, so if ECMULT_GEN_PREC_BITS is fine, then this constant should be ./configure-able as in #596. See this commit for reference: 2842dc5

@douglasbakkum Do you want to give it a try?

douglasbakkum · 2019-05-31T14:05:23Z

@real-or-random Yea, agree. If it is quick for you, would you mind doing so?

… precomputed table for signing from bitcoin-core/secp256k1#337

vhnatyk · 2019-06-19T12:19:57Z

Hi! any progress with this?

douglasbakkum · 2019-06-21T13:36:10Z

Sorry for the delays. My colleague @benma made a commit to make the value configurable.

real-or-random · 2019-07-12T12:45:11Z

Ah I haven't seen the changes. I'll have a look next week!

real-or-random

With ./configure --disable-openssl-tests --with-ecmult-gen-precision=8 (but not 2 and 4) and valgrind ./exhaustive_tests I get millions of warnings like

==6831== Invalid read of size 16
==6831==    at 0x1111AB: secp256k1_fe_add (field_5x52_impl.h:405)
==6831==    by 0x1111AB: secp256k1_gej_double_var.part.0.constprop.0 (group_impl.h:358)
==6831==    by 0x1154ED: secp256k1_gej_double_var (group_impl.h:326)
==6831==    by 0x1154ED: secp256k1_ecmult_gen_context_build (ecmult_gen_impl.h:83)
==6831==    by 0x11A55E: secp256k1_context_preallocated_create (secp256k1.c:130)
==6831==    by 0x11A55E: secp256k1_context_create (secp256k1.c:142)
==6831==    by 0x109130: main (tests_exhaustive.c:460)
==6831==  Address 0x1ffedfe740 is on thread 1's stack
==6831==  in frame #1, created by secp256k1_ecmult_gen_context_build (group_impl.h:29)
==6831==
==6831== Invalid read of size 16
==6831==    at 0x1111B0: secp256k1_fe_add (field_5x52_impl.h:405)
==6831==    by 0x1111B0: secp256k1_gej_double_var.part.0.constprop.0 (group_impl.h:358)
==6831==    by 0x1154ED: secp256k1_gej_double_var (group_impl.h:326)
==6831==    by 0x1154ED: secp256k1_ecmult_gen_context_build (ecmult_gen_impl.h:83)
==6831==    by 0x11A55E: secp256k1_context_preallocated_create (secp256k1.c:130)
==6831==    by 0x11A55E: secp256k1_context_create (secp256k1.c:142)
==6831==    by 0x109130: main (tests_exhaustive.c:460)
==6831==  Address 0x1ffedfe730 is on thread 1's stack
==6831==  in frame #1, created by secp256k1_ecmult_gen_context_build (group_impl.h:29)
==6831==
==6831== Invalid write of size 4
==6831==    at 0x1111B5: secp256k1_fe_add (field_5x52_impl.h:412)
==6831==    by 0x1111B5: secp256k1_gej_double_var.part.0.constprop.0 (group_impl.h:358)
==6831==    by 0x1154ED: secp256k1_gej_double_var (group_impl.h:326)
==6831==    by 0x1154ED: secp256k1_ecmult_gen_context_build (ecmult_gen_impl.h:83)
==6831==    by 0x11A55E: secp256k1_context_preallocated_create (secp256k1.c:130)
==6831==    by 0x11A55E: secp256k1_context_create (secp256k1.c:142)
==6831==    by 0x109130: main (tests_exhaustive.c:460)
==6831==  Address 0x1ffedfe75c is on thread 1's stack
==6831==  in frame #1, created by secp256k1_ecmult_gen_context_build (group_impl.h:29)
==6831==
==6831== Invalid write of size 8
==6831==    at 0x1111C8: secp256k1_fe_add (field_5x52_impl.h:405)
==6831==    by 0x1111C8: secp256k1_gej_double_var.part.0.constprop.0 (group_impl.h:358)
==6831==    by 0x1154ED: secp256k1_gej_double_var (group_impl.h:326)
==6831==    by 0x1154ED: secp256k1_ecmult_gen_context_build (ecmult_gen_impl.h:83)
==6831==    by 0x11A55E: secp256k1_context_preallocated_create (secp256k1.c:130)
==6831==    by 0x11A55E: secp256k1_context_create (secp256k1.c:142)
==6831==    by 0x109130: main (tests_exhaustive.c:460)
==6831==  Address 0x1ffedfe740 is on thread 1's stack
==6831==  in frame #1, created by secp256k1_ecmult_gen_context_build (group_impl.h:29)

I haven't looked at this further.

real-or-random · 2019-07-15T08:23:13Z

configure.ac

+AC_ARG_WITH([ecmult-gen-precision], [AS_HELP_STRING([--with-ecmult-gen-precision=2|4|8|auto],
+[Precision bits to tune the precomputed table size for signing.]
+[The size of the table is 32kB for 2 bits, 64kB for 4 bits, 512kB for 8 bits of precision.]
+[A smaller table size usually results in slower signing.]


nit: maybe phrase it the around way around: "A larger table size usually results in possible faster signing."

(to be consistent with "Larger values result in possibly better performance" for the other config entry)

With ./configure --disable-openssl-tests --with-ecmult-gen-precision=8 (but not 2 and 4) and valgrind ./exhaustive_tests I get millions of warnings like

There is no issue if you call it like this:

valgrind --max-stackframe=2097912 ./exhaustive_tests

Reference:

-max-stackframe= [default: 2000000]
The maximum size of a stack frame. If the stack pointer moves by more than this amount then Valgrind will assume that the program is switching to a different stack.
You may need to use this option if your program has large stack-allocated arrays.

Seems like the big option just needs more stack space. It's a valgrind heuristic only and the tests run fine otherwise.

Will add a note to the README.

Oh indeed, thanks!

real-or-random · 2019-07-15T08:26:29Z

src/gen_context.c

@@ -45,23 +46,23 @@ int main(int argc, char **argv) {
    fprintf(fp, "#define _SECP256K1_ECMULT_STATIC_CONTEXT_\n");
    fprintf(fp, "#include \"src/group.h\"\n");
    fprintf(fp, "#define SC SECP256K1_GE_STORAGE_CONST\n");
-    fprintf(fp, "static const secp256k1_ge_storage secp256k1_ecmult_static_context[64][16] = {\n");
+    fprintf(fp, "static const secp256k1_ge_storage secp256k1_ecmult_static_context[ECMULT_GEN_PREC_N][ECMULT_GEN_PREC_G] = {\n");


Thanks, looks good!
Can you add a sentence like "Try deleting ecmult_static_context.h before the build." or similar?

real-or-random · 2019-07-15T08:47:36Z

Makefile.am

@@ -172,7 +172,7 @@ src/ecmult_static_context.h: $(gen_context_BIN)
 CLEANFILES = $(gen_context_BIN) src/ecmult_static_context.h $(JAVAROOT)/$(JAVAORG)/*.class .stamp-java
 endif

-EXTRA_DIST = autogen.sh src/gen_context.c src/basic-config.h $(JAVA_FILES)
+EXTRA_DIST = autogen.sh src/gen_context.c src/libsecp256k1-config.h src/basic-config.h $(JAVA_FILES)


I don't think we want to distribute src/libsecp256k1-config.h. It will be generated by configure.

Can you add a sentence like "Try deleting ecmult_static_context.h before the build." or similar?

Done.

I don't think we want to distribute src/libsecp256k1-config.h. It will be generated by configure.

That was a misguided attempt at having gen_context rebuild the static context upon configuration change. It seems to work now anyway, so I removed it again.

Oh hm, apparently make distcheck fails here:
https://travis-ci.org/bitcoin-core/secp256k1/jobs/558864214#L847

On a second thought, I'm not sure that including src/libsecp256k1-config.h is a good idea. There are downstream users of this library (e.g., https://github.com/rust-bitcoin/rust-secp256k1) that don't use the autotools. But I'm not sure what the best thing is. Maybe including it only if ECMULT_GEN_PREC_BITS is not defined. Sounds pragmatic to me.

real-or-random

Sorry for bringing up more and more stuff. We should be really close now. :)

real-or-random · 2019-07-15T11:34:02Z

README.md

+
+With valgrind, you might need to increase the max stack size:
+
+    $ valgrind --max-stackframe=2097912 ./exhaustive_tests


I need slightly larger values.... Maybe recommend 2500000?

real-or-random · 2019-07-15T11:36:29Z

src/gen_context.c

@@ -4,9 +4,10 @@
 * file COPYING or http://www.opensource.org/licenses/mit-license.php.*
 **********************************************************************/

+#include "libsecp256k1-config.h" // for ECMULT_GEN_PREC_BITS


It's not crucial but we should make sure that this warning disappears:
/configure --disable-openssl-tests --with-ecmult-gen-precision=8 --enable-experimental --enable-module-recovery --enable-module-ecdh --with-ecmult-window=22 CC=clang

In file included from src/gen_context.c:9: src/basic-config.h:33: warning: "ECMULT_WINDOW_SIZE" redefined 33 | #define ECMULT_WINDOW_SIZE 15 | In file included from src/gen_context.c:7: src/libsecp256k1-config.h:18: note: this is the location of the previous definition 18 | #define ECMULT_WINDOW_SIZE 22

I guess other compilers warn, too.

In the end it does not matter what ECMULT_WINDOW_SIZE is for use in gen_context.c. I think sticking to 15 is reasonable (but the fact that we ignore the config setting here should be more prominent in the source).

In the end it does not matter what ECMULT_WINDOW_SIZE is for use in gen_context.c. I think sticking to 15 is reasonable (but the fact that we ignore the config setting here should be more prominent in the source).

Actually it does not matter too much because gen_context does not use ECMULT_WINDOW_SIZE at all.

Fixed via #undef ECMULT_WINDOW_SIZE in basic-config.h, like with the other definitions.

@real-or-random sorry to bug, seems ok now? 😊

Ping @real-or-random - seems we are really close now :P

real-or-random · 2019-09-04T17:31:16Z

Yes, we're close. :)

ACK 1d26b27 (mod squashing) I read the changes, and tested them both with and without static precomputation, with different precision values and also with valgrind.

Can you squash some of the commits?

real-or-random · 2019-09-04T17:44:30Z

@sipa Can you have look at this? I think you know the algorithm best.

sipa · 2019-09-04T18:29:41Z

Code review ACK 1d26b27. Looks great; all comments I wanted to make were addressed in later commits.

Please squash the fixup commits.

elichai · 2019-09-04T18:46:28Z

Maybe better docs to differentiate the different between ecmult_static_precomputation,ecmult-window,ecmult-gen-precision?

benma · 2019-09-04T21:36:45Z

@elichai okay to do this in a different PR? Not strictly related.

real-or-random · 2019-09-05T05:34:11Z

I think this can happen in a different PR.

elichai · 2019-09-05T05:37:11Z

Sure, just getting to a lot of tables that it's getting confusing which table will affect what.

make ECMULT_GEN_PREC_BITS configurable ecmult_static_context.h: add compile time config assertion (#3) - Prevents accidentally using a file which was generated with a different configuration. README: mention valgrind issue With --with-ecmult-gen-precision=8, valgrind needs a max stack size adjustment to not run into a stack switching heuristic: http://valgrind.org/docs/manual/manual-core.html > -max-stackframe= [default: 2000000] > The maximum size of a stack frame. If the stack pointer moves by more than this amount then Valgrind will assume that the program is switching to a different stack. You may need to use this option if your program has large stack-allocated arrays. basic-config: undef ECMULT_WINDOW_SIZE before (re-)defining it

douglasbakkum · 2019-09-05T07:24:16Z

Thanks all.
The commits are now squashed and rebased.

real-or-random

ACK dcb2e3b verified that all changes to the previous ACKed 1d26b27 were due to the rebase

jonasnick

ACK dcb2e3b read the code and tested various configurations with valgrind

dcb2e3b variable signing precompute table (djb) Pull request description: This pull request gives an option to reduce the precomputed table size for the signing context (`ctx`) by setting `#define ECMULT_GEN_PREC_BITS [N_BITS]`. Motivation: Per #251 and #254, the static table can be reduced to 64kB. However, this is still too big for some of my embedded applications. Setting `#define ECMULT_GEN_PREC_BITS 2` produces a 32kB table at a tradeoff of about 75% of the signing speed. Not defining this value will default to the existing implementation of 4 bits. Statistics: ``` ECMULT_GEN_PREC_BITS = 1 Precomputed table size: 32kB ./bench_sign ecdsa_sign: min 195us / avg 200us / max 212us ECMULT_GEN_PREC_BITS = 2 Precomputed table size: 32kB ./bench_sign ecdsa_sign: min 119us / avg 126us / max 134us ECMULT_GEN_PREC_BITS = 4 (default) Precomputed table size: 64kB ./bench_sign ecdsa_sign: min 83.5us / avg 89.6us / max 95.3us ECMULT_GEN_PREC_BITS = 8 Precomputed table size: 512kB ./bench_sign ecdsa_sign: min 96.4us / avg 99.4us / max 104us ``` Only values of 2 and 4 make sense. 8 bits causes a larger table size with no increase in speed. 1 bit runs, actually, but does not reduce table size and is slower than 2 bits. ACKs for top commit: real-or-random: ACK dcb2e3b verified that all changes to the previous ACKed 1d26b27 were due to the rebase jonasnick: ACK dcb2e3b read the code and tested various configurations with valgrind Tree-SHA512: ed6f68ca23ffdc4b59d51525336b34b25521233537edbc74d32dfb3eafd8196419be17f01cbf10bd8d87ce745ce143085abc6034727f742163f7e5f13f26f56e

vhnatyk · 2019-09-05T19:30:56Z

So happy this got merged finally!) Hopefully I can start getting rid of black magik in my code now))

e10439c scripted-diff: rename privkey with seckey in secp256k1 interface (Pieter Wuille) ca8bc42 Drop --disable-jni from libsecp256k1 configure options (Pieter Wuille) ddc2419 Update MSVC build config for libsecp256k1 (Pieter Wuille) 67f232b Squashed 'src/secp256k1/' changes from b19c000..2ed54da (Pieter Wuille) Pull request description: It's been abound a year since the subtree was updated. Here is a list of the included PRs: * bitcoin-core/secp256k1#755: Recovery signing: add to constant time test, and eliminate non ct operators * bitcoin-core/secp256k1#754: Fix uninit values passed into cmov * bitcoin-core/secp256k1#752: autoconf: Use ":" instead of "dnl" as a noop * bitcoin-core/secp256k1#750: Add macOS to the CI * bitcoin-core/secp256k1#701: Make ec_ arithmetic more consistent and add documentation * bitcoin-core/secp256k1#732: Retry if r is zero during signing * bitcoin-core/secp256k1#742: Fix typo in ecmult_const_impl.h * bitcoin-core/secp256k1#740: Make recovery/main_impl.h non-executable * bitcoin-core/secp256k1#735: build: fix OpenSSL EC detection on macOS * bitcoin-core/secp256k1#728: Suppress a harmless variable-time optimization by clang in memczero * bitcoin-core/secp256k1#722: Context isn't freed in the ECDH benchmark * bitcoin-core/secp256k1#700: Allow overriding default flags * bitcoin-core/secp256k1#708: Constant-time behaviour test using valgrind memtest. * bitcoin-core/secp256k1#710: Eliminate harmless non-constant time operations on secret data. * bitcoin-core/secp256k1#718: Clarify that a secp256k1_ecdh_hash_function must return 0 or 1 * bitcoin-core/secp256k1#714: doc: document the length requirements of output parameter. * bitcoin-core/secp256k1#682: Remove Java Native Interface * bitcoin-core/secp256k1#713: Docstrings * bitcoin-core/secp256k1#704: README: add a section for test coverage * bitcoin-core/secp256k1#709: Remove secret-dependant non-constant time operation in ecmult_const. * bitcoin-core/secp256k1#703: Overhaul README.md * bitcoin-core/secp256k1#689: Remove "except in benchmarks" exception for fp math * bitcoin-core/secp256k1#679: Add SECURITY.md * bitcoin-core/secp256k1#685: Fix issue where travis does not show the ./tests seed… * bitcoin-core/secp256k1#690: Add valgrind check to travis * bitcoin-core/secp256k1#678: Preventing compiler optimizations in benchmarks without a memory fence * bitcoin-core/secp256k1#688: Fix ASM setting in travis * bitcoin-core/secp256k1#684: Make no-float policy explicit * bitcoin-core/secp256k1#677: Remove note about heap allocation in secp256k1_ecmult_odd_multiples_table_storage_var * bitcoin-core/secp256k1#647: Increase robustness against UB in secp256k1_scalar_cadd_bit * bitcoin-core/secp256k1#664: Remove mention of ec_privkey_export because it doesn't exist * bitcoin-core/secp256k1#337: variable sized precomputed table for signing * bitcoin-core/secp256k1#661: Make ./configure string consistent * bitcoin-core/secp256k1#657: Fix a nit in the recovery tests * bitcoin-core/secp256k1#650: secp256k1/src/tests.c: Properly handle sscanf return value * bitcoin-core/secp256k1#654: Fix typo (∞) * bitcoin-core/secp256k1#583: JNI: fix use sig array * bitcoin-core/secp256k1#644: Avoid optimizing out a verify_check * bitcoin-core/secp256k1#652: README.md: update instruction to run tests * bitcoin-core/secp256k1#651: Fix typo in secp256k1_preallocated.h * bitcoin-core/secp256k1#640: scalar_impl.h: fix includes * bitcoin-core/secp256k1#655: jni: Use only Guava for hex encoding and decoding * bitcoin-core/secp256k1#634: Add a descriptive comment for secp256k1_ecmult_const. * bitcoin-core/secp256k1#631: typo in comment for secp256k1_ec_pubkey_tweak_mul () * bitcoin-core/secp256k1#629: Avoid calling _is_zero when _set_b32 fails. * bitcoin-core/secp256k1#630: Note intention of timing sidechannel freeness. * bitcoin-core/secp256k1#628: Fix ability to compile tests without -DVERIFY. * bitcoin-core/secp256k1#627: Guard memcmp in tests against mixed size inputs. * bitcoin-core/secp256k1#578: Avoid implementation-defined and undefined behavior when dealing with sizes * bitcoin-core/secp256k1#595: Allow to use external default callbacks * bitcoin-core/secp256k1#600: scratch space: use single allocation * bitcoin-core/secp256k1#592: Use trivial algorithm in ecmult_multi if scratch space is small * bitcoin-core/secp256k1#566: Enable context creation in preallocated memory * bitcoin-core/secp256k1#596: Make WINDOW_G configurable * bitcoin-core/secp256k1#561: Respect LDFLAGS and #undef STATIC_PRECOMPUTATION if using basic config * bitcoin-core/secp256k1#533: Make sure we're not using an uninitialized variable in secp256k1_wnaf_const(...) * bitcoin-core/secp256k1#617: Pass scalar by reference in secp256k1_wnaf_const() * bitcoin-core/secp256k1#619: Clear a copied secret key after negation * bitcoin-core/secp256k1#612: Allow field_10x26_arm.s to compile for ARMv7 architecture ACKs for top commit: real-or-random: ACK e10439c I verified the diff (subtree matches my local tree, manual inspection of other commits) but I didn't tested the resulting code fanquake: ACK e10439c Sjors: ACK e10439c jonasnick: reACK e10439c Tree-SHA512: eb6284a485da78e9d2ed3f771df85560d47c770ebf480a0d4121ab356ad26be101a2b973efe412f26e6c142bc1dbd2efbb5cc08774233e41918c59fe3dff3387

douglasbakkum mentioned this pull request Oct 18, 2015

Low-footprint mode #189

Open

douglasbakkum mentioned this pull request Mar 22, 2016

use secp ecc lib by default, with smaller precomputed table for signing BitBoxSwiss/mcu#142

Merged

real-or-random reviewed May 24, 2019

View reviewed changes

douglasbakkum closed this May 24, 2019

douglasbakkum force-pushed the master branch from abcaa73 to 1a02d6c Compare May 24, 2019 09:37

douglasbakkum reopened this May 24, 2019

douglasbakkum force-pushed the master branch from 4ca3222 to 333fab9 Compare May 24, 2019 10:35

douglasbakkum force-pushed the master branch from 333fab9 to bd0d0fb Compare May 29, 2019 14:26

vhnatyk added a commit to vhnatyk/rust-secp256k1 that referenced this pull request Jun 18, 2019

refreshed secp256k1 C sources with PR rust-bitcoin#377 variable sized…

dbc9d46

… precomputed table for signing from bitcoin-core/secp256k1#337

This was referenced Jun 18, 2019

Implementing pre allocation context creation rust-bitcoin/rust-secp256k1#116

Closed

Dev/vhnat/new master elichai/rust-secp256k1#1

Closed

douglasbakkum force-pushed the master branch from 9d270c1 to df3224d Compare June 21, 2019 13:56

real-or-random reviewed Jul 15, 2019

View reviewed changes

real-or-random requested a review from sipa September 4, 2019 17:43

sipa approved these changes Sep 4, 2019

View reviewed changes

douglasbakkum force-pushed the master branch from 1d26b27 to dcb2e3b Compare September 5, 2019 07:21

real-or-random approved these changes Sep 5, 2019

View reviewed changes

jonasnick approved these changes Sep 5, 2019

View reviewed changes

real-or-random merged commit dcb2e3b into bitcoin-core:master Sep 5, 2019

benma mentioned this pull request Oct 8, 2019

rebase on bitcoin-core/secp256k1 BlockstreamResearch/secp256k1-zkp#85

Closed

vhnatyk mentioned this pull request Oct 19, 2019

Clarify RAM footprint on MCUs rust-bitcoin/rust-secp256k1#122

Closed

gmaxwell mentioned this pull request Nov 9, 2019

Don't put an absurd amount of data onto the stack in some configs #692

Closed

sipa mentioned this pull request Jun 9, 2020

Update libsecp256k1 subtree bitcoin/bitcoin#19228

Merged


		With valgrind, you might need to increase the max stack size:

		$ valgrind --max-stackframe=2097912 ./exhaustive_tests

variable sized precomputed table for signing #337

variable sized precomputed table for signing #337

Conversation

douglasbakkum commented Oct 18, 2015

douglasbakkum commented Oct 18, 2015

gmaxwell commented Oct 18, 2015

douglasbakkum commented Oct 18, 2015

jonasschnelli commented Oct 18, 2015

ddustin commented Oct 23, 2018

gmaxwell commented May 23, 2019

real-or-random commented May 23, 2019

real-or-random May 24, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

real-or-random commented May 24, 2019

douglasbakkum commented May 24, 2019

douglasbakkum commented May 24, 2019 • edited Loading

real-or-random commented May 24, 2019

gmaxwell commented May 25, 2019

gmaxwell commented May 29, 2019

gmaxwell commented May 29, 2019

real-or-random commented May 30, 2019

douglasbakkum commented May 31, 2019

vhnatyk commented Jun 19, 2019

douglasbakkum commented Jun 21, 2019

real-or-random commented Jul 12, 2019

real-or-random left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benma Jul 15, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

real-or-random left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

real-or-random commented Sep 4, 2019

real-or-random commented Sep 4, 2019

sipa commented Sep 4, 2019 • edited Loading

elichai commented Sep 4, 2019

benma commented Sep 4, 2019

real-or-random commented Sep 5, 2019

elichai commented Sep 5, 2019

douglasbakkum commented Sep 5, 2019

real-or-random left a comment

Choose a reason for hiding this comment

jonasnick left a comment

Choose a reason for hiding this comment

vhnatyk commented Sep 5, 2019

real-or-random May 24, 2019 •

edited

Loading

douglasbakkum commented May 24, 2019 •

edited

Loading

benma Jul 15, 2019 •

edited

Loading

sipa commented Sep 4, 2019 •

edited

Loading