When a SwapDialog gets initiated with a recv_amount_sat through the
receive tab the Max Button and edits are disabled and the user is forced
to do a swap with the preset amount. Maybe the user wants to do a larger
swap?
Also suggest a submarine swap if the user creates a 0 amount invoice and
has 0 sat incoming liquidity as it won't be possible to receive
anything.
Users potentially just open a channel, then want to create a lightning invoice
without amount like they are used to from onchain addresses, and then
wonder why receiving doesn't work. So we should at least propose a swap
if there is no inbound liquidity at all.
instead of hardcoding 20_000 sat directly in the code, make
MIN_SWAP_AMOUNT_SAT a const variable outside of SwapManager so it can be
used for other code too.
- fix: qml gui errors when trying to open a wallets with only keystore-encryption
- fixes https://github.com/spesmilo/electrum/issues/10171
- qml gui to prompt for password on wallet open even if wallet is not storage-encrypted
```
28.99 | I | util.DebugMem | Start memscan
29.10 | E | plugin.Plugins |
Traceback (most recent call last):
File "...\electrum\util.py", line 405, in run_jobs
job.run()
File "...\electrum\util.py", line 376, in run
self.mem_stats()
File "...\electrum\util.py", line 368, in mem_stats
if isinstance(obj, class_):
File "...\Python310\lib\abc.py", line 119, in __instancecheck__
return _abc_instancecheck(cls, instance)
File "...\electrum\simple_config.py", line 609, in __getattribute__
raise AttributeError()
AttributeError
```
Removes the persisted payment info from lnworker once a swap got failed.
Stops persisting the OnionRoutingFailure as it is sufficient to delete
the payment info to fail potential incoming htlcs.
Deletes stored swap leftovers in lnworker and SwapManager
'prepayment', which corresponds to the trusted part of the
lightning payment.
We use 2*sm.mining_fee, where 'mining_fee' is the flat part of
the server fee. However, future protocol should probably allow
to set a value that does not depend on 'mining_fee'.
(note that LND uses a hardcoded amount).
1. Do not remove local transaction in find_base_tx.
This logic was intended to cleanup claim transactions that are
never broadcast (for example, if the counterparty gets a refund)
(see 1bf1de36cb)
However, this code is too unspecific and may result in fund loss,
because the transaction being removed may contain outgoing payments.
For example, if the electrum server is not responsive, the tx will
be seen as local and deleted. In that case, another payment will
be attempted, thus paying twice.
2. Do not remove tx after try_broadcasting returns False.
The server might be lying to us. We can only remove the local tx
if there is a base_tx, because the next tx we create will try to
spend the same output.
