Inheritance was overkill here, and now we can use inheritance for new functionality X
without having to create classes for all combinations of {X, is_testnet}.
We accept either when decoding - this only changes what we use when encoding.
Single quotes are annoying to use in a shell, as they often need to be escaped.
We have supported sending to any witness version since Electrum 3.0, using
addresses as specified in BIP-0173 (bech32 encoding).
BIP-0350 makes a breaking change in address encoding, and recommends using
(and using only) a new encoding (bech32m) for sending to witness version 1
and later. The address encoding for currently in use witness v0 addresses
remains the same, as in BIP-0173; following the BIP-0350 spec.
closes https://github.com/spesmilo/electrum/issues/6949
related:
cd3885c0fb/bip-0350.mediawikihttps://github.com/bitcoin/bitcoin/pull/20861
Since #6014, pyaes is not really needed anymore.
As we currently require either one of pycryptodomex or cryptography,
even if pyaes is available, it will not be used.
We could strip it out completely from crypto.py...
In any case, pyaes is still pulled in by some hw wallet dependencies indirectly;
but the core library no longer depends on it.
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.
