Exposes reverse submarine swaps to an external/specific address in the
TxEditor gui as "Submarine Payments". The user can enter a onchain
address in the Send Tab and then pay it from the lightning balance in
the send tab by enabling the Submarine Payments option in the TxEditor
dialog menu and switching to the Submarine Payment tab in the Tab bar.
Currently on master the qml fee histogram colours are calculated for feerates clamped to [1, 600] sat/vbyte. I want to extend it to now cover [0, 600] sat/vbyte.
I would like to extend it in a way that does not change the existing colour meanings/mapping, so not just e.g. doing an offset.
follow-up https://github.com/spesmilo/electrum/commit/bd6dfc53a234b01376d0de4221756125f256ef1a
This changes the "Pay to" label to "Pay to many" if the user enables the
"Pay to many" option and aligns it at the top of the payto_e instead of
moving ot to the center when the payto_e expands.
The toolbar button is very small and some users probably don't even
notice it. As we have lots of space in the toolbar anyways i think it
makes sense to add some text to it to make it more visible and easier to
click. Maybe this is also useful for screen readers.
The amount edit box is not turning red anymore if the amount is higher
than the wallet balance, so this string can be removed.
Alternatively it could be made red again but seems like nobody missed
it.
Allow to open the BalanceDialog, by clicking on the Pie Diagram in the
bottom left corner of the main window, if there is an active warning,
even if the wallets balance is 0. Right now the user can see the
warning icon for the lighting channel reserve, but cannot click on the
icon to read the actual warning if there is no balance in the wallet.
The string is not translated and might not be accessible for non-english
speakers, even though its relatively self-explanatory i think adding
this emoji makes it more accessible.
The ServerWidget was not working properly, when switching from "Manual
Mode" to "Auto Connect" the change wouldn't get saved as it depended on
having a correct server string entered (which isn't neccessary for Auto
Connect).
Also makes the widget behave more sane by cleaning the server input if
Auto Connect is enabled and switching to Manual Mode if the user
manually selects a server.
Update the ServerWidget every time it is shown (on initialization and
also when the user opens it again or switches between network dialog
tabs).
This will clean it up if the user has entered some invalid server and
closes it, otherwise this server would stay in the input field until the
application is restarted.
The list of servers in the ServerWidget allows the user to right click
and 'Use as server' on the servers in the list, however internally it
was handled differently than what the user would expect when clicking on
'Use as server'. E.g. if the user selects a server in autoconnect mode
it would still stay in autoconnect mode so the server could switch again
to another server any time? Now it will also change the mode to manual
(or stay in single server mode if that was selected before), making it
clear that this server will stay selected.
If the user clicks on "Follow this branch" the connect mode will get changed to
autoconnect as internally we connect to a random interface on this
branch.
Enforce that the information used to create a bolt11 invoice using
`get_bolt11_invoice()` is similar to the related instance of PaymentInfo
by requiring a PaymentInfo as argument for `get_bolt11_invoice()`.
This way the invoice cannot differ from the created PaymentInfo.
This allows to use the information in PaymentInfo for validation of
incoming htlcs more reliably.
To cover all required information for the creation of a b11 invoice the
PaymentInfo class has to be extended with a expiry and
min_final_cltv_expiry. This requires a db upgrade.
I don't understand what the "coins not used" comment meant here.
It was added in the change away from the old config.WALLET_BATCH_RBF option
(https://github.com/spesmilo/electrum/commit/ab14c3e1382c1af48baff73b790aecfbd069eb8a).
The `coins` param *is used* in wallet.get_candidates_for_batching.
Without setting that, the returned set of candidates was restricted to
only base txs that had a large enough change output to cover *all* the newly added outputs.
Instead, it is desirable to allow adding new inputs.
Replace calls to deprecated asyncio.iscoroutinefunction with calls to
inspect.iscoroutinefunction to prevent the following deprecation
warnings from showing up if running with Python 3.14:
```
/home/user/code/electrum-fork/electrum/util.py:1225: DeprecationWarning: 'asyncio.iscoroutinefunction' is deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead
assert asyncio.iscoroutinefunction(func), 'func needs to be a coroutine'
/home/user/code/electrum-fork/electrum/util.py:507: DeprecationWarning: 'asyncio.iscoroutinefunction' is deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead
if asyncio.iscoroutinefunction(func):
/home/user/code/electrum-fork/electrum/util.py:1246: DeprecationWarning: 'asyncio.iscoroutinefunction' is deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead
assert asyncio.iscoroutinefunction(func), 'func needs to be a coroutine'
/home/user/code/electrum-fork/electrum/lnpeer.py:272: DeprecationWarning: 'asyncio.iscoroutinefunction' is deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead
assert asyncio.iscoroutinefunction(func), 'func needs to be a coroutine'
/home/user/code/electrum-fork/electrum/util.py:1225: DeprecationWarning: 'asyncio.iscoroutinefunction' is deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead
assert asyncio.iscoroutinefunction(func), 'func needs to be a coroutine'
/home/user/code/electrum-fork/electrum/util.py:507: DeprecationWarning: 'asyncio.iscoroutinefunction' is deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead
if asyncio.iscoroutinefunction(func):
```
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?
I think _wallet_key_from_path should not raise.
This is probably the sane way to deal with this.
Though all this is assuming that os.path.realpath can be treated as consistent/stateless.
closes https://github.com/spesmilo/electrum/issues/10182
Even though the exception dialog inherits from ElDialog the padding
didn't work as it overwrites the properties of the ElDialog. So the
padding has to be applied separately to the ExceptionDialog.
binds the walletCanReceive variable to the available inbound liquidity
so the withdraw button gets enabled when the channels reconnect if the
user opens a lnurlw request dialog before the channels have connected.
separates the resolving step from the QEInvoiceParser so the 'recipient'
can be resolved first and then either an QEInvoiceParser can be used if
it is a sending request that has been resolved (invoice, address,
lnurlp, ...), or RequestDetails can be used if the resolved 'recipient'
turns out to be a voucher/LNURLW string.
# Conflicts:
# electrum/gui/qml/qeinvoice.py
adds handling of lnurl-withdraw payment identifiers which allow users to
withdraw bitcoin from a service by scanning a qr code or pasting the
lnurl-w code as "sending" address.
add some padding at the bottom of the LoadingWalletDialog so the
spinning circle is not directly at the bottom of the dialog, looks a bit
nicer this way.
ThomasV