storage encryption.
The password will be needed on startup with anchor channels.
Note that it remains possible to use non-encrypted storage
and keystore encryption with the command line.
The wayland plugin would require at least debian 12 (or ubuntu 22.04) at runtime.
see https://github.com/spesmilo/electrum/pull/9189#pullrequestreview-2309983943 :
> I've now tried running the appimage on debian 10 (oldoldstable), and am getting an error with wayland.
>
> ```
> 4.16 | D | util.profiler | Plugins.__init__ 0.0422 sec
> 4.16 | I | daemon.Daemon | launching GUI: qt
> 4.76 | I | gui.qt.ElectrumGui | Qt GUI starting up... Qt=6.7.1, PyQt=6.7.1
> /tmp/.mount_electrFlGFOt/usr/bin/python3: symbol lookup error: /tmp/.mount_electrFlGFOt/usr/lib/python3.11/site-packages/PyQt6/Qt6/plugins/platforms/../../lib/libQt6WaylandClient.so.6: undefined symbol: wl_proxy_marshal_flags
> ```
>
> If I explicitly specify `QT_QPA_PLATFORM=xcb`, it starts and works as expected. But it picks wayland by default.
> I found https://bugreports.qt.io/browse/QTBUG-114635 and it looks like even debian 11 might be affected.
I noticed that when running from source on macOS, the OS menubar has an "About Python" menu item,
instead of an "About Electrum" menu item. I tried to fix that by this, but actually it is not working :P
Nevertheless, this looks useful at least on Linux and Windows. E.g. when instantiating a new dialog
without an explicit title, the qt application name is used as default.
The application name, without this change AFAICS was already "Electrum" when running any of the binaries.
However when running from source, it was in some cases "python" or "run_electrum" or even "electrum-4"
(depending on OS and how the main script is started).
Now it is consistent -- except on macOS it still is not, as there it really wants to look for a .plist...
```
25.30 | E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/gui/qt/__init__.py", line 439, in _start_wizard_to_select_or_create_wallet
wallet = self.daemon.load_wallet(wallet_file, d['password'], upgrade=True)
File "/home/user/wspace/electrum/electrum/daemon.py", line 481, in func_wrapper
return func(self, *args, **kwargs)
File "/home/user/wspace/electrum/electrum/daemon.py", line 491, in load_wallet
wallet = self._load_wallet(path, password, upgrade=upgrade, config=self.config)
File "/home/user/wspace/electrum/electrum/util.py", line 481, in do_profile
o = func(*args, **kw_args)
File "/home/user/wspace/electrum/electrum/daemon.py", line 516, in _load_wallet
raise WalletUnfinished(db)
electrum.wallet_db.WalletUnfinished: <electrum.wallet_db.WalletDB object at 0x7f11db3a7ca0>
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/gui/qt/wizard/wizard.py", line 203, in on_next_button_clicked
if self.is_finalized(wd):
File "/home/user/wspace/electrum/electrum/gui/qt/wizard/wallet.py", line 178, in is_finalized
if not wizard_data['wallet_exists'] or wizard_data['wallet_is_open']:
KeyError: 'wallet_exists'
```
The following exceptions should be expected:
FileNotFoundError: given wallet path does not exist
StorageReadWriteError: given file is not readable/writable or containing folder is not writable
InvalidPassword: wallet requires a password but no password or an invalid password was given
WalletFileException: any internal wallet data issue. specific subclasses can be caught separately:
- WalletRequiresSplit: wallet needs splitting (split_data passed in Exception)
- WalletRequiresUpgrade: wallet needs upgrade, and no upgrade=True was passed to load_wallet
- WalletUnfinished: wallet file contains an action and needs additional information to finalize. (WalletDB passed in exception)
Removed qml/qewalletdb.py
This patch also fixes load_wallet calls in electrum/scripts and adds a qml workaround for dialogs opening and closing so
fast that the dialog opened==true property change is missed (which we need to manage the dialog/page stack)
A new config API is introduced, and ~all of the codebase is adapted to it.
The old API is kept but mainly only for dynamic usage where its extra flexibility is needed.
Using examples, the old config API looked this:
```
>>> config.get("request_expiry", 86400)
604800
>>> config.set_key("request_expiry", 86400)
>>>
```
The new config API instead:
```
>>> config.WALLET_PAYREQ_EXPIRY_SECONDS
604800
>>> config.WALLET_PAYREQ_EXPIRY_SECONDS = 86400
>>>
```
The old API operated on arbitrary string keys, the new one uses
a static ~enum-like list of variables.
With the new API:
- there is a single centralised list of config variables, as opposed to
these being scattered all over
- no more duplication of default values (in the getters)
- there is now some (minimal for now) type-validation/conversion for
the config values
closes https://github.com/spesmilo/electrum/pull/5640
closes https://github.com/spesmilo/electrum/pull/5649
Note: there is yet a third API added here, for certain niche/abstract use-cases,
where we need a reference to the config variable itself.
It should only be used when needed:
```
>>> var = config.cv.WALLET_PAYREQ_EXPIRY_SECONDS
>>> var
<ConfigVarWithConfig key='request_expiry'>
>>> var.get()
604800
>>> var.set(3600)
>>> var.get_default_value()
86400
>>> var.is_set()
True
>>> var.is_modifiable()
True
```
- case 1: in version 4.4.1, 4.4.2, the qml GUI wizard allowed creating multisig wallets with an old_mpk as cosigner.
- case 2: in version 4.4.0, 4.4.1, 4.4.2, the qml GUI wizard allowed creating multisig wallets with mixed xpub/Ypub/Zpub.
The corresponding missing input validation was a bug in the wizard, it was unintended behaviour. Validation was added in d2cf21fc2b. Note however that there might be users who created such wallet files.
Re case 1 wallet files: there is no version of Electrum that allows spending from such a wallet. Coins received at addresses are not burned, however it is technically challenging to spend them. (unless the multisig can spend without needing the old_mpk cosigner in the quorum).
Re case 2 wallet files: it is possible to create a corresponding spending wallet for such a multisig, however it is a bit tricky. The script type for the addresses in such a heterogeneous xpub wallet is based on the xpub_type of the first keystore. So e.g. given a wallet file [Yprv1, Zpub2] it will have sh(wsh()) scripts, and the cosigner should create a wallet file [Ypub1, Zprv2] (same order).
Technically case 2 wallet files could be "fixed" automatically by converting the xpub types as part of a wallet_db upgrade. However if the wallet files also contain seeds, those cannot be converted ("standard" vs "segwit" electrum seed).
Case 1 wallet files are not possible to "fix" automatically as the cosigner using the old_mpk is not bip32 based.
It is unclear if there are *any* users out there affected by this. I suspect for case 1 it is very likely there are none (not many people have pre-2.0 electrum seeds which were never supported as part of a multisig who would also now try to create a multisig using them); for case 2 however there might be.
This commit breaks both case 1 and case 2 wallets: these wallet files can no longer be opened in new Electrum, an error message is shown and the crash reporter opens. If any potential users opt to send crash reports, at least we will know they exist and can help them recover.
The qt, qml, and kivy GUIs have a first-start network-setup screen
that allows the user customising the network settings before creating a wallet.
Previously the daemon used to create the network and start it, before this screen,
before the GUI even starts. If the user changed network settings, those would
be set on the already running network, potentially including restarting the network.
Now it becomes the responsibility of the GUI to start the network, allowing this
first-start customisation to take place before starting the network at all.
The qt and the qml GUIs are adapted to make use of this. Kivy, and the other
prototype GUIs are not adapted and just start the network right away, as before.
