Test all ecmult functions with many j*2^i combinations

[sipa]

Instead of just testing properties of the points xG for x=-36..36:

• also compute all xG where x=j*2^i for i=0..255 and odd j=1..255.
• test them against known exact results (SHA256 all of them, and compared against an independently created result)
• test all 4 ecmult functions (and for secp256k1_ecmult and secp256k1_ecmult_multi_var, both as G, and through the generic point input)

[real-or-random]

ACK ec6dff0 diff looks good

[jonasnick]

ACK mod nit

[real-or-random]

@sipa Can you fix this? This will be helpful for testing #988 .

[robot-dreams]

ACK ec6dff0

I don't have enough context to comment on the choice of test cases (e.g. whether there are other precomputed values that would be good to test), but the test itself looks good and passes locally.

I also checked against an independent Python implementation and got the exact same SHA256 output.

[sipa]

Rebased, addressed some comments, and made some more changes.

[sipa]

FWIW, the Python code to recreate the hash (in the https://github.com/bitcoin/bitcoin/tree/22.0/test/function directory):

from test_framework import key
import hashlib

s = hashlib.sha256()

def add(s, v):
    v = v % key.SECP256K1_ORDER
    if v == 0:
        s.update(b"\x00")
    else:
        keyb = v.to_bytes(32, 'big')
        ec = key.ECKey()
        ec.set(keyb, False)
        s.update(ec.get_pubkey().get_bytes())

for i in range(0, 37):
    add(s, i)
    add(s, -i)

for b in range(256):
  for v in range(1, 256, 2):
    add(s, v << b)

print(s.hexdigest())

[robot-dreams]

ACK 8ed167b

• Verified again with independent implementation, hash still matches
• Build timeout doesn't seem related to this change; ./configure --with-valgrind=yes; make; make check passed locally

Edit: My mistake, running make check locally isn't the way to reproduce what happened in CI

[real-or-random]

Hm, the re-run didn't work. @sipa Can you increase the timeout or decrease TEST_ITERS for the valgrind build?

[real-or-random]

@sipa needs trivial rebase :/

[sipa]

Rebased, but I don't think the CI failures are related to any change in this PR?

[real-or-random]

@sipa You rebased on the wrong branch.

https://github.com/sipa/secp256k1/tree/202104_ecmult_bitcomb says "This branch is 1 commit ahead, 158 commits behind bitcoin-core:master."

[real-or-random]

ACK 5eb519e

[jonasnick]

ACK 5eb519e

[jonasnick]

nit: thats more than 10 times what's required for a single point to go into the strauss batch codepath.

[sipa]

Fair, but I think it's small enough not to matter.