ServerProxy does not seem to be thread-safe.
For e.g. a 2of3 multisig wallet, which would send two messages,
one msg would get sent but the other might error out. See trace:
E | plugins.cosigner_pool.qt.Plugin | on_failure
Traceback (most recent call last):
File "...\electrum\electrum\gui\qt\util.py", line 832, in run
result = task.task()
File "...\electrum\electrum\plugins\cosigner_pool\qt.py", line 199, in <lambda>
task = lambda: server.put(_hash, message)
File "...\Python38\lib\xmlrpc\client.py", line 1109, in __call__
return self.__send(self.__name, args)
File "...\Python38\lib\xmlrpc\client.py", line 1450, in __request
response = self.__transport.request(
File "...\Python38\lib\xmlrpc\client.py", line 1153, in request
return self.single_request(host, handler, request_body, verbose)
File "...\Python38\lib\xmlrpc\client.py", line 1165, in single_request
http_conn = self.send_request(host, handler, request_body, verbose)
File "...\Python38\lib\xmlrpc\client.py", line 1271, in send_request
connection.putrequest("POST", handler, skip_accept_encoding=True)
File "...\Python38\lib\http\client.py", line 1088, in putrequest
raise CannotSendRequest(self.__state)
http.client.CannotSendRequest: Request-sent
- for symmetry with other plugins
- and because this is a superset. txin.utxo gets populated from the wallet db (or network);
but the wallet db does not import txs from txin.utxo (so if a psbt already had an
unknown tx there, it will not get imported)
Inform the user that they need to upgrade if their firmware version is
out of date.
The previous `check_device_firmware_version()` was dead code, and the
bb02 function called inside also does not exist.
This commit adds support for the BitBox02 hardware wallet.
It supports both single and multisig for the electrum gui wallet.
To use the plugin a local installation of the BitBox02 python library is
required. It can be found on PiPy under the name 'bitbox02' and can be
installed from the bitbox02-firmware repository in the py/bitbox02
directory.
All communication to and from the BitBox02 is noise encrypted, the keys
required for this are stored in the wallet config file under the
bitbox02 key.
The BitBox02 registers a multisig configuration before allowing
transaction signing. This multisig configuration includes the threshold,
cosigner xpubs, keypath, a variable to indicate for mainnet and testnet,
and a name that the user can choose during configuration registration.
The user is asked to register the multisig configuration either during
address verification or during transaction signing.
The check the xpub of the BitBox02 for other hardware wallets, a button
is added in the wallet info dialog.
The wallet encryption key is fetched in a separate api call, requiring a
slightly tweaked override version of the wallet encryption password.
scenario1:
- 2of2 multisig wallet with trezor1 and trezor2 keystores
- only trezor2 connected
- previously we would pair first keystore with connected device and then display error.
now we will pair the device with the correct keystore on the first try
scenario2:
- standard wallet with trezor1 keystore
- trezor2 connected (different device)
- previously we would pair trezor2 with the keystore and then display error.
now we will prompt the user to select which device to pair with (out of one)
related: #5789
Just makes sense in general.
Also, previously, the GUI would freeze if right after startup the user
clicked the hww status bar icon (especially with multiple hww connected).
E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "...\electrum\electrum\plugins\ledger\ledger.py", line 167, in perform_hw1_preflight
firmwareInfo = self.dongleObject.getFirmwareVersion()
File "...\Python38\site-packages\btchip\btchip.py", line 561, in getFirmwareVersion
response = self.dongle.exchange(bytearray(apdu))
File "...\Python38\site-packages\btchip\btchipComm.py", line 127, in exchange
raise BTChipException("Invalid status %04x" % sw, sw)
btchip.btchipException.BTChipException: Exception : Invalid status 6faa
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "...\electrum\electrum\gui\qt\main_window.py", line 120, in onPress
self.func()
File "...\electrum\electrum\plugins\hw_wallet\qt.py", line 260, in show_settings_dialog
device_id = self.choose_device(window, keystore)
File "...\electrum\electrum\plugins\hw_wallet\qt.py", line 253, in choose_device
info = self.device_manager().select_device(self, keystore.handler, keystore)
File "...\electrum\electrum\plugin.py", line 554, in select_device
infos = self.unpaired_device_infos(handler, plugin, devices)
File "...\electrum\electrum\plugin.py", line 545, in unpaired_device_infos
soft_device_id=client.get_soft_device_id()))
File "...\electrum\electrum\plugins\ledger\ledger.py", line 88, in get_soft_device_id
self._soft_device_id = self.request_root_fingerprint_from_device()
File "...\electrum\electrum\plugins\hw_wallet\plugin.py", line 197, in request_root_fingerprint_from_device
child_of_root_xpub = self.get_xpub("m/0'", xtype='standard')
File "...\electrum\electrum\plugins\ledger\ledger.py", line 55, in catch_exception
return func(self, *args, **kwargs)
File "...\electrum\electrum\plugins\ledger\ledger.py", line 103, in get_xpub
self.checkDevice()
File "...\electrum\electrum\plugins\ledger\ledger.py", line 210, in checkDevice
self.perform_hw1_preflight()
File "...\electrum\electrum\plugins\ledger\ledger.py", line 198, in perform_hw1_preflight
raise UserFacingException("Dongle is temporarily locked - please unplug it and replug it again")
electrum.util.UserFacingException: Dongle is temporarily locked - please unplug it and replug it again
When initialising a Trezor as part of the wallet creation,
device_info.label is still the old (None) label in on_hw_derivation.
This is because device_info was created during the initial scan.
related: #6063
previously, client.handler was sometimes
- an InstallWizard
- a QtHandlerBase where win was an ElectrumWindow
- a QtHandlerBase where win was an InstallWizard
- a CmdLineHandler
That's just too much dynamic untyped undocumented polymorphism...
Now it will never be an InstallWizard (replaced with QtHandlerBase where win is an InstallWizard),
and now in all cases client.handler is an instance of HardwareHandlerBase, yay.
related: #6063
