Python 3.8 changed where DLLs are searched for.
see https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew
This potentially affect our binaries when we start shipping python 3.8+, however that is not being addressed here. This commit simply addresses the usecase of running from source, on Windows, using python 3.8.
On older Python, a user could build/obtain DLLs and place them anywhere on the system %PATH%, however this no longer works with py3.8, as %PATH% is no longer checked.
With py3.8, instead, we now check if there is a folder named '.dlls' in the top-level project directory, and if so, register that as an additional search path.
A user who wants to run Electrum from source on Windows using python 3.8 or later, with their custom DLLs, should manually create the '.dlls' folder and put their DLLs there. If they also want to switch between e.g. python 3.7 and 3.8, they should also include '.dlls' in the system %PATH%.
When using Electrum, interesting DLLs include at least libsecp256k1.dll, libusb-1.0.dll, libzbar-0.dll.
widget.show() and widget.setVisible(True) results in a blink of an ephemeral window containing the widget;
that is, unless the widget has a parent explicitly set or it can be determined via which layout the widget is placed in.
.../electrum/electrum/gui/qt/paytoedit.py:221: DeprecationWarning: an integer is required (got type float). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
self.setMinimumHeight(h)
A variant of WaitingDialog that runs the task in the GUI thread,
blocking the GUI. It is probably a code smell to actually use this,
as operations should not block the GUI... still it provides a middle-ground
between blocking the GUI without giving user-feedback and having to refactor
existing code (to avoid blocking).
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.
For example, for 50 KB of random data, and base 43,
previously,
- base_encode took ~38 seconds
- base_decode took ~270 seconds
now,
- base_encode takes ~7.5 seconds
- base_decode takes ~6 seconds
note: tests needed changing due to behavioural change in wallet.get_receiving_address()
Previously wallet.get_receiving_address used wallet.db.get_addr_history,
now it (indirectly) uses wallet.get_address_history, which now also considers local txns.
not sure what it is supposed to catch...
The examples I could come up with would all be actual bugs;
in which case we should let the exception propagate out to the crash reporter.
Scenario: select some UTXOs in the 'Coins' tab. Create a tx and sign it.
Close the tx dialog without broadcasting/etc (cancel tx).
Signatures would remain for selected UTXOs.
Create new tx -> invalid sigs.
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)
SomberNight