secp256k1_fe_mul_int
rather than the slower secp256k1_fe_mul
.
secp256k1_fe_mul_int
rather than the slower secp256k1_fe_mul
.
128+
129 print("")
130 print("")
131 print("/* To be put in src/group_impl.h: */")
132+for f in sorted(gens.keys()):
133+ # Use as generator/2 the one with lowest b, and lowest (x, y) generator (interpreted as integers).
I guess it doesn’t matter but take min(generator/2) instead of just min(generator)?
0 # Use as generator/2 the one with lowest b, and lowest (x, y) generator (interpreted as non-negative integers).
I guess it doesn’t matter but take min(generator/2) instead of just min(generator)?
I don’t understand what you’re suggesting here.
172 print("# error No known generator for the specified exhaustive test group order.")
173 print("# endif")
174+print("#else")
175+print("static const secp256k1_ge secp256k1_ge_const_g = SECP256K1_G;")
176+output_b(7)
177+print("#endif")
0print("#else")
1print()
2print("static const secp256k1_ge secp256k1_ge_const_g = SECP256K1_G;")
3output_b(7)
4print()
5print("#endif")
I think this improves readability of the output a lot. Same for the other #else
/#elif
branches.
122+ print(" 0x%08x, 0x%08x, 0x%08x, 0x%08x,\\" % tuple((int(g[1]) >> (32 * (7 - i))) & 0xffffffff for i in range(4)))
123+ print(" 0x%08x, 0x%08x, 0x%08x, 0x%08x\\" % tuple((int(g[1]) >> (32 * (7 - i))) & 0xffffffff for i in range(4, 8)))
124+ print(")")
125+
126+def output_b(b):
127+ print(f"#define SECP256K1_B {int(b)}U")
U
? secp256k1_fe_mul_int
takes a signed int.
secp256k1_fe_mul_int
should be changed to take an unsigned as input…
126+def output_b(b):
127+ print(f"#define SECP256K1_B {int(b)}U")
128+
129 print("")
130 print("")
131 print("/* To be put in src/group_impl.h: */")
Generated by ...
Great :)
This should touch also touch the exhaustive tests code touched in https://github.com/bitcoin-core/secp256k1/commit/b110c106fa9704e30f6b0c2ffa6a2697031e89a8, at least the comments.
When running the sage script locally, I noticed that it outputs a group of order 7, too. Did you omit this on purpose when copying the output of the script the C files?
Anyway, the exhaustive tests break don’t compile for this order of 7. Here’s a branch that fixes this problem and also has fixups (please squash) to your commits which include the 7 group (plus further formatting nits, what I actually had in mind here #1192 (review)): https://github.com/real-or-random/secp256k1/commits/202301_small_b
This comment of mine is still unaddressed:
This should touch also touch the exhaustive tests code touched in b110c10, at least the comments.
Sorry, I didn’t foresee that my comment about using mul_int
in #1118 gets us sidetracked so much… ^^
When running the sage script locally, I noticed that it outputs a group of order 7, too. Did you omit this on purpose when copying the output of the script the C files?
No, for me the output does not include size 7:
0Analyzing curve y^2 = x^3 + 6
1- Finding subgroups
2- Analyzing subgroup of order 2
3 - Bad size
4- Analyzing subgroup of order 7
5 - No endomorphism for this subgroup
6- Analyzing subgroup of order 2
7 - Bad size
8...
Anyway, the exhaustive tests break don’t compile for this order of 7. Here’s a branch that fixes this problem and also has fixups (please squash) to your commits which include the 7 group (plus further formatting nits, what I actually had in mind here #1192 (review)): https://github.com/real-or-random/secp256k1/commits/202301_small_b
Bizarre that 7 actually works (your branch compiles, and the exhaustive tests pass…).
This comment of mine is still unaddressed:
This should touch also touch the exhaustive tests code touched in b110c10, at least the comments.
I have no idea what you’re trying to say.
Bizarre that 7 actually works (your branch compiles, and the exhaustive tests pass…).
Found it!
y^2 = x^3 + 6
actually has two subgroups of order 7, leading to 48 valid generators. Only 12 of those generators generate a group which admit a GLV endomorphism. Apparently Sage versions report different generators, which means the code in this PR may or may not find a GLV-compatible one. Fixing.
I have no idea what you’re trying to say.
Oh, I had missed you were talking about the C code touched there. Indeed, will address.
ACK ce60785b2654e60b43577dd75996b7020afbfec8 also ran the exhaustive tests with the group of size 7
I still think that https://github.com/real-or-random/secp256k1/commit/7eef8f4a305a72567db0b563260081712304b5fb is a good cleanup but we can also add it after this PR
edit: I guess we want to stick with the group of size 13 as a default? It’s reasonably fast.
For our future curious minds:
000:44 <sipa> Let G1 and G2 be generators of the two endomorphism-compatible order-7 subgroups.
100:46 <sipa> Let C_i be the subgroup consisting of itG1 + tG2 for t=0..6 (with i=infinity for the group consisting of tG1).
200:47 <sipa> Then beta*C_i lands you in C_{2i}.
300:47 <sipa> If i=0 or i=inf, it's an endomorphism.
401:20 <sipa> Ah! And there is a much simpler explanation.
501:21 <sipa> With the same two generators G1,G2 above, beta-multiplying a*G1 + b*G2 gives 2*a*G1 + 4*b*G2.
601:21 <sipa> If you started off with a*G1, you get twice your input, so lambda=2.
701:22 <sipa> If you started off with b*G2, you get 4 times your input, so lambda=4.
801:22 <sipa> But if you started off with a linear combination with non-zero contributions from both, you get a different linear combination that's not a pure multiple back.
901:24 <sipa> Put otherwise, for any independent generators G1,G2 of the order-49 subgroup, if you think of the elements as vectors with basis G1,G2, then beta-multiplication is effectively a linear transformation on those vectors.
1001:24 <sipa> That linear transformation has eigenvalues 2 and 4.
1101:25 <sipa> The subgroup consisting of eigenvectors corresponding to eigenvalue 2 is the subgroup in which the endomorphism works, with lambda=2.
1201:25 <sipa> Same with eigenvalue 4.