This fixes a regression where the plugin was assuming ordering for
txin.pubkeys (which is now a set).
(previously txin.pubkeys was a list ordered according to the final
sort order of keys inside the bitcoin script)
- the DeviceMgr no longer uses xpubs to keep track of paired hw devices
- instead, introduce keystore.pairing_code(), based on soft_device_id
- xpubs are now only used in a single place when the actual pairing happens
- motivation is to allow pairing a single device with multiple generic
output script descriptors, not just a single account-level xpub
- as a side-effect, we now allow pairing a device with multiple open
windows simultaneously (if keystores have the same root fingerprint
-- was already the case before if keystores had the same xpub)
e.g.
```
Debug message
jade: (error getting device infos)
Missing libraries for jade.
ModuleNotFoundError("No module named 'cbor'")
Make sure you install it with python3
```
I had a ledger nano S and a ledger nano S plus connected at the same time,
and the "id_"s were colliding resulting in weird behaviour. Multisig was pretty
much not usable with both devices connected simultaneously.
Example dicts returned by `hid.enumerate(0, 0)`:
{'path': b'\\\\?\\hid#vid_2c97&pid_1015&mi_00#a&2a30{REDACTED}&0&0000#{REDACTED_UUID}', 'vendor_id': 11415, 'product_id': 4117, 'serial_number': '0001', 'release_number': 513, 'manufacturer_string': 'Ledger', 'product_string': 'Nano S', 'usage_page': 65440, 'usage': 1, 'interface_number': 0},
{'path': b'\\\\?\\hid#vid_2c97&pid_5011&mi_00#a&28d{REDACTED}&0&0000#{REDACTED_UUID}', 'vendor_id': 11415, 'product_id': 20497, 'serial_number': '0001', 'release_number': 513, 'manufacturer_string': 'Ledger', 'product_string': 'Nano S Plus', 'usage_page': 65440, 'usage': 1, 'interface_number': 0}
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).
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
This was done to calculate the bip32 root fingerprint but it broke
the digitalbitbox. The keystore already had a different way to get
the root fingerprint for existing wallets, specifically handling this
case; the code in base_wizard used when creating new wallets was
duplicating that code originally and was then forgotten to be updated.
Now these codepaths are unified.
closes#5816
we should not raise generic Exception when wanting to communicate with
the user. it makes distinguishing programming errors and messages hard,
as the caller will necessarily need to catch all Exceptions then
