Note: the checksum was already being checked in practically all cases, by the caller.
Moved the check here, to the lower level (but still public) method for sanity.
note: low R grinding would not have to be duplicated if we trusted the caller
to have done it already (as is the case with the classes in ecc.py), and if
we propagated the choice of "random_k" as part of the nonce_function passed
to libsecp256k1 (which is not currently done)
The few other cases that used SimpleConfig.get_instance() now
either get passed a config instance, or they try to get a reference
to something else that has a reference to a config.
(see lnsweep, qt/qrcodewidget, qt/qrtextedit)
time taken to add points changes to around 35% of what it was with python-ecdsa
-----
# benchmark runs before:
> python3.7-64 ..\wspace\201909_libsecp256k1_point_addition\bench.py
time taken: 3.7693 seconds
> python3.7-64 ..\wspace\201909_libsecp256k1_point_addition\bench.py
time taken: 3.8123 seconds
> python3.7-64 ..\wspace\201909_libsecp256k1_point_addition\bench.py
time taken: 3.7937 seconds
# benchmark runs after:
> python3.7-64 ..\wspace\201909_libsecp256k1_point_addition\bench.py
time taken: 1.3127 seconds
> python3.7-64 ..\wspace\201909_libsecp256k1_point_addition\bench.py
time taken: 1.3000 seconds
> python3.7-64 ..\wspace\201909_libsecp256k1_point_addition\bench.py
time taken: 1.3128 seconds
-----
# benchmark script:
import os
import time
from electrum.ecc import generator
from electrum.crypto import sha256
rand_bytes = os.urandom(32)
#rand_bytes = bytes.fromhex('d3d88983b91ee6dfd546ccf89b9a1ffb23b01bf2eef322c2808cb3d951a3c116')
point_pairs = []
for i in range(30000):
rand_bytes = sha256(rand_bytes)
rand_int = int.from_bytes(rand_bytes, "big")
a = generator() * rand_int
rand_bytes = sha256(rand_bytes)
rand_int = int.from_bytes(rand_bytes, "big")
b = generator() * rand_int
point_pairs.append((a,b))
t0 = time.time()
for a, b in point_pairs:
c = a + b
t = time.time() - t0
print(f"time taken: {t:.4f} seconds")
This bug is triggered if ecc_fast._libsecp256k1 and/or
crypto.AES are not present.
Before, if the first test would have raised an exception
it would have been implicitly caught by returning from
the finally block and hence this effectively masks the
test's outcome. Now, the exception is properly propagated
causing the test to fail if an exception is raised.
