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)
```
(well, not everything, only files in electrum/ (so e.g. not contrib))
See comment in setup.py.
E.g. we have been including the www/ folder in the tar.gz but have not been installing it
to site-packages. Now we do.
Or we have been including the kivy GUI files in the tar.gz but not installing them.
Now we do.
I like this because it simplifies setup.py and should be easier to reason about too.
should fix#7089 (at least when using the tar.gz)
The `git clean --dry-run` became redundant with "fresh clone" builds.
The new exclude in MANIFEST.in should not affect production builds (also due to fresh clone),
but they are nice when building from dirty local dir.
Note that this will not fix the value for already existing channels
that have been created with onchain backup; one would need a wallet_db
upgrade in order to fix them (probably not worth the effort).
ThomasV
SomberNight
Axel Gembe
krzysobo