see #7158
```
$ ./contrib/pull_locale
Found 260 files to translate
Generate template
electrum/gui/qt/installwizard.py:265: warning: Empty msgid. It is reserved by GNU gettext:
gettext("") returns the header entry with
meta information, not the empty string.
electrum/gui/qt/channels_list.py:49: warning: Empty msgid. It is reserved by GNU gettext:
gettext("") returns the header entry with
meta information, not the empty string.
```
E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "...\electrum\electrum\gui\qt\main_window.py", line 870, in timer_actions
self.update_wallet()
File "...\electrum\electrum\gui\qt\main_window.py", line 1003, in update_wallet
self.update_tabs()
File "...\electrum\electrum\gui\qt\main_window.py", line 1010, in update_tabs
self.history_model.refresh('update_tabs')
File "...\electrum\electrum\util.py", line 412, in <lambda>
return lambda *args, **kw_args: do_profile(args, kw_args)
File "...\electrum\electrum\util.py", line 408, in do_profile
o = func(*args, **kw_args)
File "...\electrum\electrum\gui\qt\history_list.py", line 329, in refresh
self.view.filter()
File "...\electrum\electrum\gui\qt\util.py", line 705, in filter
self.hide_rows()
File "...\electrum\electrum\gui\qt\util.py", line 709, in hide_rows
self.hide_row(row)
File "...\electrum\electrum\gui\qt\util.py", line 685, in hide_row
should_hide = self.should_hide(row_num)
File "...\electrum\electrum\gui\qt\history_list.py", line 445, in should_hide
date = tx_item['date']
KeyError: 'date'
Previously for incoming transports, the diagnostic_name (for log messages)
was just "responder" -- not sufficient to distinguish peers.
We now use the pubkey instead.
For outgoing transports it is f"{host}:{port}" (unchanged).
We could just use the pubkey for both uniformly; but it is quite long, and
it is hard to distinguish them at a glance.
(related to prev commit, but really another bug)
If we had two peers with the same pubkey (peer A in the process of teardown, peer B ~freshly connected),
peer A might remove peer B from lnworker.peers via close_and_cleanup().
rm `close_and_cleanup()` call from reestablish_channel - it was added
as a workaround for this bug (in 8b95b2127d)
before we understood the cause.
If a remote node tries to establish a transport with us but we already
have an open transport with such a node id, there are two sane ways to go, either:
- keep existing transport open, reject new transport
- close existing transport, establish new transport
We could do either; I chose to do the second option here, as that is what
lnd and eclair seem to be doing.
Previously we would get into an inconsistent state: both transports open,
but only one of them stored in lnworker.peers.
Previously the min() was passed lightning amounts and on-chain amounts mixed;
which is conceptually a type error. It is now only passed on-chain amounts.
Due to the bug, we did not allow a swap to fully exhaust out "LN receive" capacity.
Now the max amt can be slighly larger.
- document SwapManager._get_recv_amount and SwapManager._get_send_amount
- change calculations so that they match the boltz-backend
- note that in the reverse swap case, the server does not care about the on-chain claim tx the client
needs to pay for. This introduced some implicit hacks and inconsistencies in the code in the past,
it is still a bit ugly but at least this is now explicit.
- SwapManager._get_recv_amount and SwapManager._get_send_amount are now proper inverses of each other
-----
Here are some code snippets to play around with in Qt console.
For the forward swap case:
```
from electrum import ecc; lnworker = wallet.lnworker; sm = lnworker.swap_manager
invoice = network.run_from_another_thread(lnworker.create_invoice(amount_msat=3000000*1000, message="swap", expiry=86400))[1]; request_data = {"type": "submarine", "pairId": "BTC/BTC", "orderSide": "sell", "invoice": invoice, "refundPublicKey": ecc.GENERATOR.get_public_key_bytes().hex()}
network.send_http_on_proxy('post', sm.api_url + '/createswap', json=request_data, timeout=30)
sm.get_send_amount(3000000, is_reverse=False)
sm.get_recv_amount(3026730, is_reverse=False)
```
For the reverse swap case:
```
from electrum import ecc; import os; lnworker = wallet.lnworker; sm = lnworker.swap_manager
request_data = {"type": "reversesubmarine", "pairId": "BTC/BTC", "orderSide": "buy", "invoiceAmount": 3000000, "preimageHash": os.urandom(32).hex(), "claimPublicKey": ecc.GENERATOR.get_public_key_bytes().hex()}
network.send_http_on_proxy('post', sm.api_url + '/createswap', json=request_data, timeout=30)
sm.get_recv_amount(3000000, is_reverse=True)
sm.get_send_amount(2974443, is_reverse=True)
```
It is not realistic to expect Electrum to be used as a watchtower
in GUI mode, and possibly counter-productive (may set wrong
expectations).
A proper watchtower should be configured as a daemon. The
documentation will be updated to reflect this change.
Ubuntu 20.04 needs `libxcb-xinerama.so.0`
and Debian 10 needs `libxcb-util.so.1` for the Qt `xcb` plugin.
-----
ported from 380f04a805
see https://github.com/Electron-Cash/Electron-Cash/issues/2196
-----
In particular, see this comment:
>> I confirmed that both Ubuntu 20.04 and Debian 10.8 clean install have an issue with the 4.2.4 AppImage.
>
> Any idea what broke it? I assume it used to work.
Yes, it did work in 4.2.3 which used PyQt5 5.13.2. I just had a look at the xcb plugin and it definitely has less dependencies:
```
ago@ubuntu2004vm:~/src/Electron-Cash/dist$ ldd squashfs-root/usr/lib/python3.6/site-packages/PyQt5/Qt/plugins/platforms/libqxcb.so|grep xcb
libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f0ec9d07000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f0ec9cdd000)
libxcb-xkb.so.1 => /lib/x86_64-linux-gnu/libxcb-xkb.so.1 (0x00007f0ec6ead000)
```
compared to PyQt5 5.15.2 in 4.2.4:
```
ago@ubuntu2004vm:~/src/Electron-Cash/dist$ ldd squashfs-root/usr/lib/python3.8/site-packages/PyQt5/Qt/plugins/platforms/libqxcb.so|grep xcb
libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007fcb5715f000)
libxcb-icccm.so.4 => /lib/x86_64-linux-gnu/libxcb-icccm.so.4 (0x00007fcb57158000)
libxcb-image.so.0 => /lib/x86_64-linux-gnu/libxcb-image.so.0 (0x00007fcb56f51000)
libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007fcb56f4c000)
libxcb-util.so.1 => /lib/x86_64-linux-gnu/libxcb-util.so.1 (0x00007fcb56d46000)
libxcb-keysyms.so.1 => /lib/x86_64-linux-gnu/libxcb-keysyms.so.1 (0x00007fcb56d41000)
libxcb-randr.so.0 => /lib/x86_64-linux-gnu/libxcb-randr.so.0 (0x00007fcb56d2e000)
libxcb-render-util.so.0 => /lib/x86_64-linux-gnu/libxcb-render-util.so.0 (0x00007fcb56d27000)
libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007fcb56d16000)
libxcb-shape.so.0 => /lib/x86_64-linux-gnu/libxcb-shape.so.0 (0x00007fcb56d11000)
libxcb-sync.so.1 => /lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007fcb56d07000)
libxcb-xfixes.so.0 => /lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007fcb56cfd000)
libxcb-xinerama.so.0 => /lib/x86_64-linux-gnu/libxcb-xinerama.so.0 (0x00007fcb56cf8000)
libxcb-xkb.so.1 => /lib/x86_64-linux-gnu/libxcb-xkb.so.1 (0x00007fcb56cda000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fcb56cae000)
```
SomberNight
ThomasV
Axel Gembe