These methods return a list of channels that can be rebalanced,
in order to receive or send a given amount.
Also add 'channels' parameter to submarine swaps.
Previously, swaps were not considering which channel to use.
When we do not have liquidity to pay an invoice:
- add 'rebalance' option in order to pay an invoice
- use the suggested channel in the 'swap' option
When we do not have the liquidity to receive an invoice:
- add 'Rebalance' and 'Swap' buttons to the receive tab
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'
```
Tolerates discrepancies in the swap amount crosschecks. To ensure we
calculate the send/receive amounts correctly we apply a check, using
amount inversion. The inversion is not exact up to +-1 due to used
floor and ceil functions in the methods. They are not invertible,
which is why we relax the check to off-by-ones.
- 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)
```
In a normal (forward) swap (onchain->offchain):
send_amount = receive_amount * (1 + service_percentage) + normal_fee ,
and vice versa:
receive_amount = (send_amount + normal_fee) / (1 + service_percentage) ,
i.e., the service fee is charged on the received offchain amount.
ThomasV