re REQUESTED_FCLOSE and WE_ARE_TOXIC (as per f321x):
> There is no reason for the peer to send channel_reestablish after we
> have sent the force close request (error) and I assume we don't
> want to give surface to the peer to attempt finding out if we really lost state?
re FORCE_CLOSING:
the peer might not have realised we started force-closing but we probably don't want to run the message-handler even in that case
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.
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.
The typical flow of an update is:
---UPDATE--->
--- SIG --->
<--REVACK----
<-- SIG ----
---REVACK--->
It makes sense to try to send a sig ("commitment_signed") right after we send an update.
It also makes sense right after we send revack.
Besides those times, we could call "maybe_send_commitment" at *any* time, that is safe, and depending on other call locations, it might be an optimisation, however it is not needed.
In particular it is unclear why we had those calls when we *receive* updates (and only for certain types of updates - not consistently).
"When should we reveal preimages onchain?"
This commit tries to simplify the thinking by making the observation:
- we can reveal preimages (actually in any context) if they are already public
- a preimage is public if any other lightning node knows it besides us
- if we learn the preimage from another LN node, it is public
- if we send update_fulfill_htlc, it becomes public
- if we see a preimage onchain, it is public
- in lnsweep._maybe_reveal_preimage_for_htlc:
- partial mpp check is not relevant if preimage is already public
- let's just always do KeepWatchingTXO, for sanity/safety
Co-authored-by: ThomasV <thomasv@electrum.org>
I noticed CLN is sending our own channel update to us on
reestablishment, we then assume it to be the remote nodes
update and try to verify the signature against their pubkey
which fails and throws `InvalidGossipMsg`.
This adds a check preventing us from trying to save our own
channel updates as remote update.
- if multiple LN-enabled wallets are open, need to know which peer is for which wallet
- note: LNGossip is a singleton
- if a wallet is named LNGossip, can't distinguish. I think that's ok.
compare log lines:
before:
```
84.82 | I | lnpeer.Peer.[LNWallet, 034cc6216f-f8dcaa6e] | Disconnecting: GracefulDisconnect('Failed to initialize: TimeoutError()')
17.97 | D | lnpeer.Peer.[LNGossip, 0259d4116d-1618547b] | Sending INIT
```
after:
```
5.80 | D | lnpeer.Peer.[test_segwit_2, 038863cf8a-fd53ef9c] | Sending CHANNEL_READY
5.92 | D | lnpeer.Peer.[LNGossip, 038863cf8a-6286ffd4] | Received INIT
```
Save the updated htlc set in `Peer._fulfill_htlc_set` and
`Peer._fail_htlc_set()` only after the loop iterated through all htlcs.
This potentially improves performance, especially considering that
writing the db can take >100 ms for larger wallets without partial
writes.
- LNWallet no longer "is-an" LNWorker, instead LNWallet "has-an" LNWorker
- the motivation is to make the unit tests nicer, and allow writing unit tests for more things
- I hope this makes it possible to e.g. test lnsweep in the unit tests
- some stuff we would previously have to write a regtest for, maybe we can write a unit test for, now
- in unit tests, MockLNWallet now
- inherits LNWallet
- the Wallet is no longer being mocked
The done_callback for the callback tasks in _run_htlc_switch_iteration
tried to access mpp_sets by key but they might already have been deleted
when the callback is called, causing an KeyError. Instead forward the
exceptions to the crash reporter so we get notice of them and they get
logged correctly.
```
20251219T131356.946565Z | ERROR | asyncio | Exception in callback Peer._run_htlc_switch_iteration.<locals>.<lambda>(<Task finishe.../util.py:1773>) at /home/user/code/electrum-fork/electrum/lnpeer.py:2907
handle: <Handle Peer._run_htlc_switch_iteration.<locals>.<lambda>(<Task finishe.../util.py:1773>) at /home/user/code/electrum-fork/electrum/lnpeer.py:2907 created at /usr/lib64/python3.14/asyncio/events.py:94>
source_traceback: Object created at (most recent call last):
File "/usr/lib64/python3.14/threading.py", line 1082, in _bootstrap_inner
self._context.run(self.run)
File "/home/user/code/electrum-fork/electrum/util.py", line 1145, in run_with_except_hook
run_original(*args2, **kwargs2)
File "/usr/lib64/python3.14/threading.py", line 1024, in run
self._target(*self._args, **self._kwargs)
File "/home/user/code/electrum-fork/electrum/util.py", line 1705, in run_event_loop
loop.run_until_complete(stopping_fut)
File "/usr/lib64/python3.14/asyncio/base_events.py", line 706, in run_until_complete
self.run_forever()
File "/usr/lib64/python3.14/asyncio/base_events.py", line 677, in run_forever
self._run_once()
File "/usr/lib64/python3.14/asyncio/base_events.py", line 2038, in _run_once
handle._run()
File "/usr/lib64/python3.14/asyncio/events.py", line 94, in _run
self._context.run(self._callback, *self._args)
Traceback (most recent call last):
File "/usr/lib64/python3.14/asyncio/events.py", line 94, in _run
self._context.run(self._callback, *self._args)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/lnpeer.py", line 2909, in <lambda>
f"{self.lnworker.received_mpp_htlcs[pk]=}", exc_info=t.exception()) if t.exception() else None
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
KeyError: '0000980000010001:1'
```
Don't remove a payment hash from LNWallet.dont_settle_htlcs and
dont_expire_htlcs if we are failing it.
We might see another htlc with the same payment hash and
should still not settle or expire it.
- lnworker.channels takes a copy of the whole dict, to make it thread-safe
- in LNWallet class, can just use self._channels.get(chan_id)
- otherwise there is lnworker.get_channel_by_id
- same for lnpeer.channels.get and lnpeer.get_channel_by_id
We tried to delete incoming channels that didn't get funded after
lnutil.CHANNEL_OPENING_TIMEOUT, however an assert prevented this:
```
3.63 | E | lnwatcher.LNWatcher.[default_wallet-LNW] | Exception in check_onchain_situation: AssertionError()
Traceback (most recent call last):
File "/home/user/code/electrum-fork/electrum/util.py", line 1233, in wrapper
return await func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/lnwatcher.py", line 117, in check_onchain_situation
await self.update_channel_state(
...<5 lines>...
keep_watching=keep_watching)
File "/home/user/code/electrum-fork/electrum/lnwatcher.py", line 135, in update_channel_state
chan.update_onchain_state(
~~~~~~~~~~~~~~~~~~~~~~~~~^
funding_txid=funding_txid,
^^^^^^^^^^^^^^^^^^^^^^^^^^
...<2 lines>...
closing_height=closing_height,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
keep_watching=keep_watching)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/lnchannel.py", line 341, in update_onchain_state
self.update_unfunded_state()
~~~~~~~~~~~~~~~~~~~~~~~~~~^^
File "/home/user/code/electrum-fork/electrum/lnchannel.py", line 382, in update_unfunded_state
self.lnworker.remove_channel(self.channel_id)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/lnworker.py", line 3244, in remove_channel
assert chan.can_be_deleted()
~~~~~~~~~~~~~~~~~~~^^
AssertionError
```
Store the channel id instead of the scid in ReceivedMPPHtlc.
The scid can be None, in theory even for multiple channels at the same
time. Using the channel_id which is always available and unique seems
less error prone at the cost of temporarily higher storage requirements
in the db for the duration of the pending htlcs.
Alternatively we could use the local scid alias however using the
channel_id seems less complex and leaves less room for ambiguity.
Deduct the just in time channel opening fees from the total amount so
htlcs don't get timed out if they come from a just in time channel with
opening fee.
Related: https://github.com/spesmilo/electrum/pull/9584
Allows storing two different payment info of the same payment hash by
including the direction into the db key.
We create and store PaymentInfo for sending attempts and for requests (receiving),
if we try to pay ourself (e.g. through a channel rebalance) the checks
in `save_payment_info` would prevent this and throw an exception.
By storing the PaymentInfos of outgoing and incoming payments separately in
the db this collision is avoided and it makes it easier to reason about
which PaymentInfo belongs where.
Use the `OnionFailureCode.INVALID_ONION_VERSION` (BADONION | PERM | 4)
code when sending back `update_fail_malformed_htlc` as just sending a plain
`BADONION` is not explicitly mentioned as correct in the spec.
Splits `LNWallet.dont_settle_htlcs` into `LNWallet.dont_settle_htlcs`
and `LNWallet.dont_expire_htlcs`.
Registering a payment hash in dont_settle_htlcs will prevent it from
getting fulfilled if we have the preimage stored. The preimage will not
be released before the the payment hash gets removed from
dont_settle_htlcs. Htlcs can still get expired as usual or failed if no
preimage is known.
This is only used by Just-in-time channel openings.
Registering a payment hash in dont_expire_htlcs allows to overwrite the
minimum final cltv delta value after which htlcs would usually get
expired. This allows to delay expiry of htlcs or, if the value in the
dont_settle_htlcs dict is None, completely prevent expiry and let the
htlc get expired onchain.
Splitting this up in two different dicts makes it more explicit and
easier to reason about what they are actually doing.
Please enter the commit message for your changes. Lines starting
It seems useful to report exceptions happening in the htlc_switch to the
crash reporter as it shouldn't raise exceptions in theory and this could
help catch subtle bugs.
refactor `htlc_switch` to new architecture to make it more robust
against partial settlement of htlc sets and increase maintainability.
Htlcs are now processed in two steps, first the htlcs are collected into
sets from the channels, and potentially failed on their own already.
Then a second loop iterates over the htlc sets and finalizes only on
whole sets.
# Conflicts:
# electrum/lnpeer.py
Add unittest to TestPeerForwarding which sends a multi trampoline
payment.
Wait another htlc_switch iteration in tests because trampolines might have different delays
Instead of storing its own path, each StoredDict element stores
its own key and a pointer to its parent. If a dict is removed
from the db, its parent pointer is set to None. This makes
self.path return None for all branches that have been pruned.
This passes tests/tests_json_db.py and fixes issue #10000
Because `LNPeer.initialized` was awaited in
`LNPeer._query_gossip()` instead of the main loop the other tasks got
spawned concurrently and each task on its own has to wait for the
initialization. In `LNPeer._send_own_gossip()` this was missing, instead
there is a fixed 10 sec sleep. If the connection was not initialized but
the 10 sec are exceeded `_send_own_gossip()` tries to send gossip and
causes this exception as the `LNTransport` is not ready:
```
2.13 | E | lnpeer.Peer.[LNWallet, 0288fa27c0-bc1900c8] | Exception in main_loop: AttributeError("'LNTransport' object has no attribute 'sk'")
Traceback (most recent call last):
File "/home/user/code/electrum-fork/electrum/util.py", line 1232, in wrapper
return await func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/lnpeer.py", line 511, in wrapper_func
return await func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/lnpeer.py", line 525, in main_loop
async with self.taskgroup as group:
^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/env/lib/python3.14/site-packages/aiorpcx/curio.py", line 304, in __aexit__
await self.join()
File "/home/user/code/electrum-fork/electrum/util.py", line 1420, in join
task.result()
~~~~~~~~~~~^^
File "/home/user/code/electrum-fork/electrum/lnpeer.py", line 573, in _send_own_gossip
self.send_node_announcement(alias, color)
~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/lnpeer.py", line 1830, in send_node_announcement
self.transport.send_bytes(raw_msg)
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/lntransport.py", line 225, in send_bytes
lc = aead_encrypt(self.sk, self.sn(), b'', l)
^^^^^^^
AttributeError: 'LNTransport' object has no attribute 'sk'. Did you mean: 'sn'?
```
By awaiting the initialization directly in the `main_loop` it is more
clear that the task getting spawned subsequently depend on the transport
being available and separates the initialization more clearly these
other functions.
Renames RecvMPPResolution.ACCEPTED to .COMPLETE as .ACCEPTED is somewhat
misleading. Accepted could imply that the preimage for this set has been
revealed or that the set has been settled, however it only means that we
have received the full set (it is complete), but the set still can be
failed (e.g. through cltv timeout) and has not been claimed yet.
ThomasV