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
(ab14c3e138).
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.
There was too much code duplication - there still is a bit...
- in some places buttons had text "Read QR code with camera", in others it was "Read QR code from camera"
- 63c224cb53 added a "on_qr_from_file_input_btn"
input method, which was not added everywhere.
- was missing in add_qr_input_combined_button and in editor_contextMenuEvent
fixes exceptions ocurring when entering a '!' amount with a payment
identifier that is not allowed to send max (e.g. bolt11).
fixes exception when "Max" is still set from previous PI and the PI gets
replaced by one that doesn't allow max sending.
This is purely informational and optional, with the main immediate use to provide the
invoice description/message/label to the transaction dialog, so it can be stored
when saving the tx in history, or passed along with PSBTs sent to cosigners.
Before, the tx description was not saved in history when an invoice was not saved before
signing and saving the tx for sending later.
There was no ability to read qr codes contained in image files. This
could lead to confusion in some contexts, as `on_file_input()` of
ScanQRTextEdit will read the whole content of the file (instead of
looking for qr codes). The revealer plugin for example generates png
files containing qr codes and uses the `ScanQRTextEdit` to get user
input, for the user it would seem logical to click on 'Read from file'
to load the generated file, however this will result in the wrong data
being loaded. Having the option to explicitly load a QR from file makes
this clear. Also it seems useful, especially considering reading QR from
screenshots doesn't work on wayland.
- Wallet.make_unsigned_transaction takes a FeePolicy parameter
- fee sliders act on a FeePolicy instead of config
- different fee policies may be used for different purposes
- do not detect dust outputs in lnsweep, delegate that to lnwatcher
- Separation between SwapManager and its transport:
Legacy transpport uses http, Nostr uses websockets
- The transport uses a context to open/close connections.
This context is not async, because it needs to be called
from the GUI
- Swapserver fees values are initialized to None instead
of 0, so that any attempt to use them before the swap
manager is initialized will raise an exception.
- Remove swapserver fees disk caching (swap_pairs file)
- Regtests use http transport
- Android uses http transport (until QML is ready)
Somewhat a follow-up to 649ce979ab.
This adds some safety belts so we don't accidentally sign a tx that
contains a dummy address.
Specifically we check that tx does not contain output for dummy addr:
- in wallet.sign_transaction
- in network.broadcast_transaction
The second one is perhaps redundant, but I think it does not hurt.
Note that HTLCs must not be cancelled after the funding transaction
has been broadcast. If one want to cancel a swap once the funding
transaction is in mempool, one should double spend the transaction.
script destinations.
This is mainly to support OP_RETURN outputs, which typically have a zero amount output value,
but as we don't special case OP_RETURN, this is currently done for all non-address scripts
Also, it's probably good to add a warning popup for OP_RETURN outputs with a non-zero output value, but this
would also need special casing for OP_RETURN.
Saving of script output payment identifiers is disabled for now, as reading the script from the stored invoice
back into human-readable form is currently not implemented, and currently only lightning invoices or address output
is supported.
