follow-up e1d34300e5
follow-up dc15d59fcf
```
Traceback (most recent call last):
File ".../electrum/gui/qt/main_window.py", line 910, in timer_actions
self.update_wallet()
File ".../electrum/gui/qt/main_window.py", line 1068, in update_wallet
self.update_tabs()
File ".../electrum/gui/qt/main_window.py", line 1075, in update_tabs
self.history_model.refresh('update_tabs')
File ".../electrum/util.py", line 439, in <lambda>
return lambda *args, **kw_args: do_profile(args, kw_args)
File ".../electrum/util.py", line 435, in do_profile
o = func(*args, **kw_args)
File ".../electrum/gui/qt/history_list.py", line 275, in refresh
transactions = wallet.get_full_history(
File ".../electrum/util.py", line 439, in <lambda>
return lambda *args, **kw_args: do_profile(args, kw_args)
File ".../electrum/util.py", line 435, in do_profile
o = func(*args, **kw_args)
File ".../electrum/wallet.py", line 1109, in get_full_history
lightning_history = self.lnworker.get_lightning_history() if self.lnworker and include_lightning else {}
File ".../electrum/lnworker.py", line 839, in get_lightning_history
assert direction == PaymentDirection.FORWARDING
AssertionError
```
follow-up fe74e4b9c9
Just for sanity -- there could be a collision of class names (defined in separate modules).
```
>>> wallet.is_up_to_date.__qualname__
'Abstract_Wallet.is_up_to_date'
>>> wallet.is_up_to_date.__module__
'electrum.wallet'
```
and use that registration in the iterator.
That way, we do not invoke getattr on arbitrary methods, which
could trigger unwanted code execution (for example, if a method
is decorated with @property, getattr will execute its code).
- the detection of self-payments was using the length
of the htlc list, incorrectly categorizing all MPPs.
- the fee for self-payments was not correctly computed.
get_unused_addresses() has been broken since #7730, because
addresses are considered as permanently used if they are in
the list of keys of receive_requests. This is true even if
an address is used as fallback for a lightning payment. This
means that the number of lightning payments we can receive
is constrained by the gap limit.
If a payment succeeds off-chain, we want to be able to reuse
its fallback address in other requests (this does not reduce
privacy, because invoices already share the same public key).
This implies that we should not use the onchain address as key
for lightning-enabled requests in wallet.receive_requests. If
we did, paid invoices would be overwritten when the address is
reused. That is the reason for the wallet_db upgrade.
Related: a3faf85e3c
- add new index: requests_rhash_to_key (fixes#7845)
- when creating a request, do not save its description in labels.
Instead, return it as default value in wallet.get_label_by_rhash
lnworker:
- rename 'payments' to 'payment_info'
- add note to delete_payment_info
commands: rename 'rmrequest' to 'delete_request'
- revert the logic of do_breach_remedy to what it was
before 0ca3d66d15,
but now calling self.maybe_redeem unconditionally.
- replace mempool transactions only if the fee increases
- do not notify the GUI if a local tx is replaced
- delete labels when replacing
When running a command, file logging is disabled as every
command-invocation would create a new logfile. However if the user
explicitly sets "-v" on the commandline, there's no reason why that
shouldn't work.
The wallet needs its own up_to_date logic:
- the adb being up_to_date means all its addresses are synced
- but an HD wallet might decide to roll the gap limit and generate new addresses
- the adb does not know about this...
- the wallet should be considered *not* up_to_date
- relatedly, it is now the wallet that decides to reset the network request counters
- note that wallet.main() was never cleaned up previously.
- now wallet gets its own taskgroup, which is cleaned up in wallet.stop.
Follow-up to adb refactor: 121d8732f1
The `WE_ARE_TOXIC` state is added as a sanity check to ensure that if
the remote has proven that we have lost state we do not accidentally
do a local force-close. E.g. if we receive an "error" message for the
channel, we might normally do an automatic force-close. Manually
force-closing in such a state is not offered anymore by the GUI.
The `REQUESTED_FCLOSE` state is added as it is quite likely that
we receive an error message from the remote after requesting a fclose,
e.g. during a later chan-reestablish. In such a scenario, we should
not do an auto-local-fclose, however the manual option of a local-fclose
should still be offered.
- separate AddressSynchronizer from Wallet and LNWatcher
- the AddressSynchronizer class is referred to as 'adb' (address database)
- Use callbacks to replace overloaded methods
