Electrum

qt: SettingsDialog: guard self.network access

Check if self.network before trying to access it. This would trigger an
exception when toggling the trampoline checkbox in offline mode:
```
29.13 | E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "/home/user/Documents/electrum/electrum/gui/qt/settings_dialog.py", line 133, in on_trampoline_checked
self.network.run_from_another_thread(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'run_from_another_thread'
31.00 | E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "/home/user/Documents/electrum/electrum/gui/qt/settings_dialog.py", line 131, in on_trampoline_checked
self.network.start_gossip()
^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'start_gossip'
```

plugin: nwc: handle missing params dict in request

Even though the NIP-47 specification kind of defines that requests should
always pass a params dict in their request i witnessed way too often
that clients don't include it in some requests where it is technically
not neccessary and we fail on it.
Handling this gracefully improves compatibility without obvious
downsides.

follow-up prev

plugin.py: fix some type hints

plugins: use decorator to early return if plugin not authorized

qt: ReceiveTab: fix flickering zeroconf message

The ReceiveTab gets updated regularly (e.g. when syncing headers).
Every time it updates we would first show the invoice and then the
zeroconf confirmation overlay. This caused the overly to appear
flickering when there are updates in higher frequency.

Also we need to keep state if the user has already confirmed the
zeroconf message for this request, otherwise the question
will re-appear each time the user clicked "Accept" and the
ReceiveTab updates again.

lnpeer: don't signal OPTION_ZEROCONF_OPT to untrusted peer

Only signal `OPTION_ZEROCONF_OPT` to peers if we either:
1. Have no trusted peer configured (assuming that we are LSP)
2. Have a trusted peer configured, and the peer we are connecting
to is this trusted peer.

Otherwise peers that are LSPs but are not the clients trusted LSP
might try to open a channel to the client but it would get rejected.

lnwallet: make jit fees configurable, add mining fees

Make the just in time channel fees and channel size
configvars, as in practice not every provider would
use the same hardcoded fees or channel sizes.
Add the mining fees required for the funding transaction on top of the
opening fees to prevent opening channels at a loss in a higher
fee environment.

tests: add unittests for LNWallet just in time opening

Adds unittests for `LNWallet.open_channel_just_in_time()`,
`LNWallet._cleanup_failed_jit_channel()`,
`LNWallet.can_get_zeroconf_channel()` and
`LNWallet.receive_requires_jit_channel()`.

open_channel_just_in_time: add cleanup and broadcast retry

Adds cleanup logic to `LNWallet.open_channel_just_in_time` so
that the channel provider removes unfunded channels again, e.g. if
the client didn't release the preimage or the provider failed
to broadcast the funding transaction.

Also adds more robust transaction broadcast logic so we retry to
broadcast if it failed and check against adb to see if any previous
broadcast was successful.

lnworker: stop setting static jit alias for jit channel

...so we can have multiple just in time channels with the same lsp.
We already save a remote scid alias in `on_channel_ready` which we
already have received after the new zeroconf channel is in open state.
So setting the alias to the static node id hash is counterproductive
because it doesn't allow to differentiate between channels.

Also extends the regtest (`just_in_time`) to do a second channel
opening, to cover this scenario. This doesn't add much runtime to
the test, so the cost seems reasonable.

lnworker/config: check if zeroconf is enabled when forwarding

On LSP side we were only checking if ACCEPT_ZEROCONF_CHANNELS
is enabled while forwarding a non-trampoline htlc.
During trampoline forwarding the config was ignored.

The ACCEPT_* prefix implied this was only for accepting inbound
zeroconf channels, but it also controls whether we open them when
forwarding HTLCs.

Renames the config var to OPEN_ZEROCONF_CHANNELS
to clarify it enables zeroconf channel opens in both directions,
and add the missing check when forwarding trampoline HTLCs.

lnchannel: fix update_unfunded_state, add unittest

Fixes AbstractChannel.update_unfunded_state to stop calling a
non-existent method (unwatch_channel).
Adds unittest to execute the zeroconf path of update_unfunded_state.

lnpeer: check just-in-time channel opening fee

Check the just-in-time channel opening fee when receiving an incoming
channel opening.

test_lnwallet: unittest trampoline invoice_feature and r_tag

Add unittest that verifies we only include r_tags for trampoline nodes
if we signal trampoline support in the invoice_features and only signal
trampoline support if we use trampoline or have only open trampoline
channels.

LNWallet: set trampoline invoice feature independently

Make the trampoline signaling in bolt11 invoices dependent upon all
unfrozen channels being with trampoline peers instead of the trampoline
config.
Stops automatically freezing non-trampoline channels for receiving if
trampoline is enabled.

One effect of this change is that now we don't signal trampoline support
anymore in the invoice even if trampoline is enabled, if one of the
channels is with a non trampoline peer.

LNWallet: only include tramp r_tags if tramp feature

Only include r_tags for trampoline nodes in a bolt11 invoice
if its invoice_features signal trampoline support.

qt gui: more defensive 'gui' RPC (i.e. URI) handling

in GUI mode, only start a limited minimal RPC server

To limit attack surface.

Context:
- both in daemon mode and in GUI mode, we start an RPC server
- the RPC server uses HTTP basic auth, with a random password that is saved in the config file
- read access to the config file implies access to the RPC server
- the traffic is unencrypted
- by default the server listens
- on Windows, on localhost TCP
- all other platform, via unix domain sockets
- if an attacker can listen to localhost TCP traffic, and there was traffic
- they could see the plaintext RPC password and issue their own commands
- e.g. if wireshark was already installed on the system, this might not require root access
- the "ping" and "gui" commands are used by everyday operations that affect most users:
- "ping" is used when trying to launch a second instance of electrum, to contact the first instance and enforce "singleton" behaviour
- "gui" is used for URI handling (`$ xdg-open bitcoin:asdasd`)
- many other sensitive commands, that operate on wallets, require *also* the wallet password
- but note that wallet.unlock can be used by the user to bypass this and store the wallet password in memory (exposed in GUI)

I propose locking down the RPC server when running in GUI mode:
- we still start it, as it is used for "ping" and "gui" RPCs, however we disable all other RPCs
- we could opt-in enable it, using a config var, except that ofc would not help against an attacker that has filesystem write access to the config file
- so I think it's even safer to just "hardcode" disable it: however the functionality is useful for development
- I propose we branch based on `constants.net.TESTNET`
- an alternative we could branch on that is hard to fake is `is_git_clone` in run_electrum

daemon: (trivial) CommandsServer.run: move tcp-specific line

this line would raise if site was a web.NamedPipeSite

fix: remove negative fee assert from get_tx_fee_warning

rm the `assert fee >= 0, f"{fee=!r} must be non-negative satoshis"`
from `Abstract_Wallet.get_tx_fee_warning()` to prevent an exception when
users load a psbt with negative tx fee.

Qt: move LN fee slider to payment dialog. fixes #10516

daemon: forbid "setconfig" command to change rpcserver settings in-flight

It is much easier to reason about the rpcserver if we don't allow changing its basic settings while it is already running. What does it mean to change the TCP port it is listening on ("rpcport") if it's already running? It is even problematic to change the rpcpassword: care needs to be taken to already update it for the current server.
(ref https://github.com/spesmilo/electrum/issues/6762)

This commit disallows changing all of the "rpc*" config variables if the daemon is already running.

---

Simultaneously, it also ensures rpc_password is always set and auth cannot be disabled.

Previously if there was a daemon running, and the user ran
`$ electrum setconfig rpcpassword ""` that would leave the RPC unauthenticated
for the current session. However next time the daemon restarted, get_rpc_credentials would see
the unset password and generate one.

I think this was the worst of both worlds:
- we did not really allow removing the rpc password, except for the current session, and
- perhaps unexpectedly, we would generate a new password on daemon restart

Instead now we explicitly make sure the RPC server can never get into a state where it does not have a password set.

Based on a report by `Zuzana Kotásková <36777@mail.vsfs.cz>`

qml: 2fa: make 2fa setup qr code clickable

This will make the 2fa app open when the user clicks on the qr code,
much more convenient than manually copy pasting the secret.

qml: 2fa: make it possible to copy 2fa secret

The 2fa secret is not selectable or copyable, this is very inconveniant
when setting up a new 2fa wallet as the user has to somehow manually
write the secret e.g. on a paper to then enter it again in their 2fa
app. This makes the secret string copyable by clicking on it.