prevents the creation of new Qt windows if the terms of use have not
been accepted yet. This is to prevent bypassing the terms of use by
starting the wallet a second time which would then skip the ToU.
Notably verifymessage and decrypt(message) were silently ignoring trailing garbage
or inserted non-base64 characters present in signatures/ciphertext.
(both the CLI commands and in the GUI)
I think it is much cleaner and preferable to treat such signatures/ciphertext as invalid.
In fact I find it surprising that base64.b64decode(validate=False) is the default.
Perhaps we should create a helper function for it that set validate=True and use that.
don't return the spending methods pay_invoice and multi_pay_invoice in
the get_info request and the info event so connections can be used for
services that enforce receive only connections.
Previously the server parameters were each handled differently, e.g. auto-connect was only applied when updating Network.server
and not when Config.autoConnect was updated. Similarly, updating Network.server did not restart the network, leading to >1 connection
when Network.oneServer was set to True before updating Network.server.
Consolidate server parameter updates into a single call, remove the individual setters, and move Config.autoConnect and Config.autoConnectDefined to Network.
the while loop in `suggest_node_channel_open()` of lnrater would not
break if there are no "good" peers available available. As a result the gui
blocks and electrum has to be killed. This can happen for example on
signet.
This removes the tested pk from the list of candidates so each candidate
gets tested only once.
- CURRENT_WALLET is set when a single wallet is loaded in memory, and it
remains set after Electrum stops running.
- If several wallets are loaded at the same time, CURRENT_WALLET is unset,
and RPCs must specify the wallet explicitly (using --wallet for the CLI)
- The fallback to 'default_wallet' essentially only applies when
creating a new wallet file
According to the asyncio documentation:
> When a task is cancelled, asyncio.CancelledError will be raised in the task at the next opportunity.
I guess the 'next opportunity' means the next await statement.
Here the issue is that the task was not awaiting ever.
Note: ElectrumX needs a similar patch
ThomasV