Fixes #1035
Changes:
- move secp256k1_ecmult_odd_multiples_table_globalz_windowa
function from ecmult to ecmult_const
- remove outdated comment
_ecmult_odd_multiples_table_globalz_windowa
#1053
Can you rebase though?
Done :)
Concept ACK, thanks for addressing this!
Though should this wait for #899 to merge first to avoid a merge conflict in that one (which is a bit longer and already has two-ish ACKs)?
Though should this wait for #899 to merge first to avoid a merge conflict in that one (which is a bit longer and already has two-ish ACKs)?
Oh, thanks for pointing this out.
11@@ -12,6 +12,22 @@
12 #include "ecmult_const.h"
13 #include "ecmult_impl.h"
14
15+/** Fill a table 'pre' with precomputed odd multiples of a.
16+ *
17+ * The resulting point set is brought to a single constant Z denominator, stores the X and Y
18+ * coordinates as ge_storage points in pre, and stores the global Z in rz.
0 * coordinates as ge_storage points in pre, and stores the global Z in globalz.
Who would have expected that the global Z is stored in globalz
?
roconnor-blockstream told me that he doesn’t mind rebasing #899 .
By the way, it’s debatable if this function should be prefixed with ecmult
or ecmult_const
… But I don’t know, the enitre ecmult_const module is not really separated from the ecmult module (reuses WINDOW_A
and the like). I believe this can be made cleaner but let’s maybe do that in a separate PR (see also #1039).
utACK 6287fa8c43736a9e187862a1ad0f7d159037e3fd (aside from @real-or-random ’s suggested comment fixup)
I agree that:
secp256k1_ecmult_odd_multiples_table_globalz_windowa
is only called from ecmult_const_impl.h
and thus should be moved therea*P + b*G
, thus the comment should be removed
Changes:
- move `secp256k1_ecmult_odd_multiples_table_globalz_windowa` function from ecmult to ecmult_const
- remove outdated comment
diff
between removed and added lines is exactly as expected)