- Wait until HTLCs are irrevocably removed before cleaning up their
data structures (MPP and forwarding)
- keep methods maybe_cleanup_mpp and maybe_cleanup_forwarding separate
- perform cleanup in htlc_switch, so that process_unfulfilled_htlc
has less side effects
- In htlc_switch, we blank the onion_packet_hex field to signal that
an HTLC has been processed. An item of chan.unfulfilled_htlcs may
go through 4 stages:
- 1. not forwarded yet: (None, onion_packet_hex)
- 2. forwarded: (forwarding_key, onion_packet_hex)
- 3. processed: (forwarding_key, None), not irrevocably removed yet
- 4. done: (forwarding_key, None), irrevocably removed
- in test_lnpeer, an extra iteration of htlc_switch has been added to
trampoline forwarding tests
follow-up https://github.com/spesmilo/electrum/commit/6fb9207a44f41acb627434ff46676278709b821b
> technically the fee estimate of a given bitcoind only changes on new blocks, but because of how we are asking for fee estimates and how we are taking the median of many interfaces, it can change at any time for us
note: running this in the peer taskgroup, for proper exception-handling and logging
If we accept a MPP and we forward the payment (trampoline or swap),
we need to persist the payment accepted status, or we might wrongly
release htlcs on the next restart.
lnworker.received_mpp_htlcs used to be cleaned up in maybe_cleanup_forwarding,
which only applies to forwarded payments. However, since we now
persist this dict, we need to clean it up also in the case of
payments received by us. This part of maybe_cleanup_forwarding has
been migrated to lnworker.maybe_cleanup_mpp
e.g. if you consolidate own utxos, the "amount sent" in the dialog is zero,
but for high fee warnings that's not the amount we should be comparing against
This will be useful if we decide to ship lntransport as a separate
package. It is also a conceptual cleanup.
Notes:
- lntransport still requires crypto.py
- parsing node id from a bolt11 invoice is not supported.
If you closed a main_window soon after opening it, and the UpdateCheckThread network request was slow
and still in progress, the gui would freeze until the network request finished.
```
=============================== warnings summary ===============================
tests/test_wizard.py::ServerConnectWizardTestCase::test_no_advanced
tests/test_wizard.py::ServerConnectWizardTestCase::test_proxy
tests/test_wizard.py::ServerConnectWizardTestCase::test_proxy_and_server
tests/test_wizard.py::ServerConnectWizardTestCase::test_server
tests/test_wizard.py::WalletWizardTestCase::test_2fa
tests/test_wizard.py::WalletWizardTestCase::test_create_standard_wallet_haveseed_bip39
tests/test_wizard.py::WalletWizardTestCase::test_create_standard_wallet_haveseed_electrum
tests/test_wizard.py::WalletWizardTestCase::test_create_standard_wallet_newseed
/tmp/cirrus-ci-build/.tox/py3/lib/python3.10/site-packages/_pytest/threadexception.py:82: PytestUnhandledThreadExceptionWarning: Exception in thread Plugins
Traceback (most recent call last):
File "/usr/local/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
self.run()
File "/tmp/cirrus-ci-build/electrum/plugin.py", line 360, in run
self.on_stop()
File "/tmp/cirrus-ci-build/electrum/util.py", line 430, in on_stop
loop = get_asyncio_loop()
File "/tmp/cirrus-ci-build/electrum/util.py", line 1578, in get_asyncio_loop
raise Exception("event loop not created yet")
Exception: event loop not created yet
warnings.warn(pytest.PytestUnhandledThreadExceptionWarning(msg))
```
The "ssl.VERIFY_X509_STRICT" flag for openssl verification has been enabled by default in python 3.13+ (it was disabled before that).
see https://github.com/python/cpython/issues/107361
and https://discuss.python.org/t/ssl-changing-the-default-sslcontext-verify-flags/30230/16
We explicitly disable it for self-signed certs, thereby restoring the pre-3.13 defaults,
as it seems to break lots of servers.
For example, using python 3.13 (or setting `sslc.verify_flags |= ssl.VERIFY_X509_STRICT`),
- I can connect to `btc.electroncash.dk:60002:s`
- but not to `electrum.emzy.de:50002:s`
despite both using self-signed certs.
We should investigate more why exactly "strict" verification fails for some self-signed certs and not for others,
and make sure that at least newly generated certs adhere to the stricter requirements (e.g. update guide in e-x?).
accumulator