I believe lightning requests created before https://github.com/spesmilo/electrum/pull/7730
can have an amount of None - ones created after have amount 0 instead.
We could do a wallet db upgrade potentially.
Regardless, the type hint is `get_amount_sat(self) -> Union[int, str, None]`,
so None should be handled. (well, arguably "!" should be handled too...)
```
E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "...\electrum\electrum\gui\qt\request_list.py", line 101, in item_changed
self.parent.show_receive_request(req)
File "...\electrum\electrum\gui\qt\main_window.py", line 1279, in show_receive_request
URI = req.get_bip21_URI(lightning=bip21_lightning)
File "...\electrum\electrum\invoices.py", line 164, in get_bip21_URI
amount = int(self.get_amount_sat())
TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'
```
```
E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "...\electrum\electrum\gui\qt\request_list.py", line 101, in item_changed
self.parent.show_receive_request(req)
File "...\electrum\electrum\gui\qt\main_window.py", line 1281, in show_receive_request
can_receive_lightning = self.wallet.lnworker and req.get_amount_sat() <= self.wallet.lnworker.num_sats_can_receive()
TypeError: '<=' not supported between instances of 'NoneType' and 'decimal.Decimal'
```
follow-up https://github.com/spesmilo/electrum/pull/7818
- note it matters whether a sender pays us end-to-end-trampoline or just via legacy
- consider: Alice has 0.1 BTC recv cap in chan1 and 1 BTC recv cap in chan2, both with border-node T1
- if sender is paying e2e trampoline, it can realistically pay even ~1.1 BTC, as T1 can resplit the HTLCs
- if sender is paying legacy, it will have a hard time trying to pay more than 1 BTC, in practice
- although note if T1 has implemented non-strict-forwarding (see BOLT-04), achieving 1 BTC is easy,
as T1 can redirect HTLCs (but cannot split them, in this case)
- to make num_sats_can_receive realistic, it assumes the legacy case
- To calc num_sats_can_receive, we sort our channels in decreasing order of receive-capacities, iterate over them
and calculate a running sum - we stop adding channels when the next chan's recv cap is small compared to
the running total.
- When putting routing hints in an invoice, we do the same, with the added condition that we keep adding channels
if their recv cap is larger than the invoice amount.
- consider: Alice has 0.1 BTC recv cap in chan1 with Bob, and 1 BTC recv cap in chan2 with Carol
- if Alice wants to recv 100 sats, it is useful to add hints for both channels into the invoice, for redundancy
- if Alice wants to recv 0.9 BTC, it is questionable whether adding the smaller chan is useful - the code here won't add it
- increase MPP_RECEIVE_CUTOFF from 5 to 20 percent
- filter channels by node_id, not channel_id
- make num_sats_can_receive consistent with routing hints
return the max value allowed for legacy payments.
(that is, do not assume we can do MPP involving two trampolines)
This reverts fb6047ec46
Reason: num_sats_can_send may be used to decide the amount
we put in a new channel.
The Qt GUI refreshes all tabs on 'blockchain_updated', which is expensive for very large wallets.
Previously, on every new block, the GUI would get one notification for each connected interface,
now only the fastest interface triggers it.
(was testing with a wallet where refreshing all tabs takes 15 seconds, and 10*15 seconds is
even more annoying...)
There is no point in adding new hww types to these lists every time support for a new hww is added.
These upgrades got released in 2.7.0 and any hw types added after are unrelated.
reverted to just-after last relevant change:
c820423b00
The keystore does not have a "client" field.
One is supposed to use the "get_client" method instead (the generic API is `plugin.get_client(keystore)`)
Remnants of old code.
It does not make sense to count change outputs in our unconfirmed balance,
because our balance will not be negatively affected if the transaction does
not get confirmed.
It is also incorrect to add signed values of get_addr_balance in order to compute
the balance over a domain. For example, this leads to incoming and outgoing
transactions cancelling out in our total unconfirmed balance.
This commit looks at the coins that are spent by a transaction. If those
coins belong to us and are confirmed, we do not count the transaction outputs
in our unconfirmed balance.
As a result, get_balance always returns positive values for unconfirmed balance.
/home/user/wspace/electrum/electrum/gui/qt/locktimeedit.py:145: DeprecationWarning: an integer is required (got type Alignment). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
painter.drawText(textRect, Qt.AlignRight | Qt.AlignVCenter, "height")
InvoiceList.update() calls hide_if_empty(), which calls setVisible().
setVisible(True) should not be called before the widget is properly parented and put into a layout,
as that results in a blank window flashing up (appearing and disappearing) briefly.
distutils (a module in the python standard library that we use) got deprecated in python 3.10,
and is planned to be removed from the stdlib in python 3.12.
see 9d38120e33/Lib/distutils/__init__.py (L16)
We only use it in the Qt update_checker (for signed version notifications), to compare version numbers.
That is, we only use a very small part of it (only `distutils.version.StrictVersion`).
```
.../electrum/electrum/gui/qt/update_checker.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
from distutils.version import StrictVersion
```
Migration advice in PEP-632 suggests ( https://peps.python.org/pep-0632/#migration-advice ):
> `distutils.version` — use the `packaging` package
Note that `packaging` is a 3rd party package, i.e. it would be a new dependency.
Also, it does not provide an identical replacement for `distutils.version.StrictVersion`.
Care needs to be taken when changing the semantics of version numbers...
E.g. `packaging.parse` and `packaging.Version` are less strict than what we currently use.
We have to be careful that old code recognises new electrum version numbers as both valid
and numerically greater than their version.
I think the easiest approach is for us to vendor this small part of distutils.
Re directory structure, this is based on `pip`:
bab5bfce50/src/pip/_vendor
(although the approach here is much more naive ofc)
The Windows build was failing due to the trailing slash in the path:
```
💬 INFO: Pip installing Electrum. This might take a long time if the project folder is large.
Processing c:\electrum
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'error'
error: subprocess-exited-with-error
python setup.py egg_info did not run successfully.
exit code: 1
[10 lines of output]
Traceback (most recent call last):
File "<string>", line 2, in <module>
File "<pip-setuptools-caller>", line 34, in <module>
File "C:\electrum\setup.py", line 75, in <module>
find_packages('electrum/', exclude=["tests", "gui.kivy", "gui.kivy.*"])]),
File "C:\python3\lib\site-packages\setuptools\discovery.py", line 103, in find
convert_path(str(where)),
File "C:\python3\lib\site-packages\setuptools\_distutils\util.py", line 130, in convert_path
raise ValueError("path '%s' cannot end with '/'" % pathname)
ValueError: path 'electrum/' cannot end with '/'
```
This is weird because I tested the setuptools.find_packages invocation on Linux, where it
has no issues with the trailing slash, but indeed it looks like on Windows it does.
Not sure why it behaves differently depending on the platform. Anyway, removing.
No change in behaviour as-is.
In the future, if we add a new folder with an __init__.py file, it will get included by default,
whereas in the past it would not.
i.e. this is changing what we manually have to specify from a whitelist to a blacklist.
Jamie C. Driver
ThomasV
SomberNight
baam25simo
gruve-p