The password should not be an empty string.
Traceback (most recent call last):
File "/opt/electrum/electrum/gui/qt/__init__.py", line 377, in start_new_window
wallet = self._start_wizard_to_select_or_create_wallet(path)
File "/opt/electrum/electrum/gui/qt/__init__.py", line 446, in _start_wizard_to_select_or_create_wallet
wallet = self.daemon.load_wallet(wallet_file, d['password'], upgrade=True)
File "/opt/electrum/electrum/daemon.py", line 461, in func_wrapper
return func(self, *args, **kwargs)
File "/opt/electrum/electrum/daemon.py", line 474, in load_wallet
wallet.unlock(password)
File "/opt/electrum/electrum/wallet.py", line 3418, in unlock
self.check_password(password)
File "/opt/electrum/electrum/wallet.py", line 3069, in check_password
raise InvalidPassword("password given but wallet has no password")
electrum.util.InvalidPassword: password given but wallet has no password
Accepting a PSBT opens the Tx dialog and pauses receiving additional PSBTs until the Tx dialog is closed.
Rejecting a PSBT will start a cooldown and accept all pending PSBTs into the history for later inspection.
- both internal and external plugins require GUI install
(except internal HW plugins, which are 'auto-loaded' and hidden)
- remove init_qt hook
- in Qt, reload wallet windows if plugin enabled/disabled
- add 'uninstall' button to PluginDialog
- add 'add plugins' button to wizard hw screen
- add icons to the plugin list
This change modifies create_trampoline_onion to only include as many
available r_tags as there is space left in the trampoline onion payload.
Previously we tried to include all passed invoice r_tags of legacy
trampoline payments into the payload which caused an user facing
exception and payment failure as the onion can only store a max of 400
bytes.
A single, single hop r_tag is around 52 bytes and the payload
without r_tags is already at ~280 bytes. So usually there is enough
space for 2 r_tags.
The implementation shuffles the r_tags on each call
so the payment will try different route hints on the attempts (fee level
increase or user retry).
I have logged the following byte sizes of the trampoline onion with a 2
trampoline onion hop and changing amounts of r_tags:
3 rtags:
payload size [0]: 113 (hop size: 81)
payload size [1]: 440 (hop size: 295) ( 52 bytes/rtag )
payload size [2]: 550 (hop size: 78)
2 rtags:
payload size [0]: 113 (hop size: 81)
payload size [1]: 386 (hop size: 241) ( 52 bytes/rtag )
payload size [2]: 496 (hop size: 78)
1 rtag:
payload size [0]: 113 (hop size: 81)
payload size [1]: 334 (hop size: 189) ( 52 bytes/rtag )
payload size [2]: 444 (hop size: 78)
0 rtags:
payload size [0]: 113 (hop size: 81)
payload size [1]: 282 (hop size: 137)
payload size [2]: 392 (hop size: 78)
As can be seen in the data, using 2 trampoline hops there is not enough
space for even a single r_tag which is why this option is being removed
too.
- this merges `contrib/deterministic-build/locale` and `electrum/locale`
- it is now once again possible have translations when running from a local git clone
- which was already possible in the past before crowdin removed their unauthenticated APIs
- see https://github.com/spesmilo/electrum/issues/9531
- however, the translations available are the often-old frozen strings from electrum-locale
- while previously one could just download the latest strings from crowdin
The option to add a 2nd trampoline hop to legacy trampoline payments requires too much space in the trampoline onion.
Because the trampoline onion has only limited space of 400b and the payload with 2nd t hop and no r_tags already requires 392b it is essentially unusable for payments that require routing hints to be included in the onion
(because the receiver has no direct channel to the 2nd trampoline node)
as there is no space left to include them (1r_tag == ~52b).
Make path calculation check if channel is not in our sending channels but still uses our nodeID as starting node of the path.
I noticed an assertion error when trying to pay an invoice from a seed i have opened channels with in different wallet instances (same seed, different wallet).
Because the channel seemed suitable for sending the payment path finding included the channel for sending in the first position of the route but then
in pay_to_route the channel for route[0] could not be found as it is not included in our channel list, causing the assert and payment to fail.
- Allow plugins saved as zipfiles in user data dir
- plugins are authorized with a user chosen password
- pubkey derived from password is saved with admin permissions
Unlike a full bitcoin node, we rarely (if ever) validate the signatures of arbitrary transactions,
so I don't think these DOS issues can really be used against us.
ref https://rubin.io/bitcoin/2025/03/11/core-vuln-taproot-dos/
ref https://github.com/bitcoin/bitcoin/pull/24105
btw what is not explained in either source link is that the lack of caching is much
more serious for taproot as bip-342 lifted the 10 kbyte max size for scriptPubKeys.
force QEDaemon singleton, and refer to QEDaemon.instance where possible
In cases where we would run into circular dependencies, pass the instance
also refer to singleton QEConfig instead of passing instance in qeapp.py
QEInvoiceParser creates a zero amount output invoice when pasting an address, which would return the
wrong status when calling wallet.get_invoice_status() (there is some address heuristic in
wallet._is_onchain_invoice_paid which is associating with the previous payment)
Sander van Grieken