rm the `assert fee >= 0, f"{fee=!r} must be non-negative satoshis"`
from `Abstract_Wallet.get_tx_fee_warning()` to prevent an exception when
users load a psbt with negative tx fee.
- could not find a single project that still actually cares about bip70 [0]
- well except maybe BitPay.
- but I cannot test with BitPay:
- they have a testnet3 staging environment on test.bitpay.com
- but the SSL cert they use for bip70 has expired in 2021
- the webUI probably also has not been updated since then...
- they claim to have added LN support in 2022 in a blog post,
but it's not there on test.bitpay.com
- on mainnet, they require KYC before payment
- < ... angry noises >
- their loss then, I don't care.
- this is code that no one wants to maintain
- this does not yet delete the signed bip70 payment data for historical txs
- but it is no longer possible to export it from the GUI
[0]: https://bitcoinops.org/en/topics/bip70-payment-protocol/
For multiple transactions, split summary in total sent/received and a balance change.
move duplicated code to wallet.get_user_notifications_for_new_txns()
Estimate the size of a base tx before stripping its signatures
so the lower bound feerate used to calculate the fee for the rbf
transaction doesn't underestimate the feerate of the base tx.
Change fees from sats to bitcoin so the fee value is consistent with the
other values.
Fixes#10445
Also adds a plugin hook so plugins can create fancy history exports.
And stops adding unconfirmed/local transactions to the history as they
are unordered and make the export non-deterministic. Also transactions
that haven't happened yet don't seem useful for accounting.
Check the swap providers liquidity as well if we try to send change to
lightning in `make_unsigned_transaction`. It is now expected that the
swap_manager is already initialized when calling
`make_unsigned_transaction`, otherwise no dummy output will get added.
- LNWallet no longer "is-an" LNWorker, instead LNWallet "has-an" LNWorker
- the motivation is to make the unit tests nicer, and allow writing unit tests for more things
- I hope this makes it possible to e.g. test lnsweep in the unit tests
- some stuff we would previously have to write a regtest for, maybe we can write a unit test for, now
- in unit tests, MockLNWallet now
- inherits LNWallet
- the Wallet is no longer being mocked
Allows storing two different payment info of the same payment hash by
including the direction into the db key.
We create and store PaymentInfo for sending attempts and for requests (receiving),
if we try to pay ourself (e.g. through a channel rebalance) the checks
in `save_payment_info` would prevent this and throw an exception.
By storing the PaymentInfos of outgoing and incoming payments separately in
the db this collision is avoided and it makes it easier to reason about
which PaymentInfo belongs where.
..also export preimage in check_hold_invoice return value if available.
I intentionally did not return the preimage in the returned dict of
wallet.export_requests as this seems risky to do considering some users
of the cli might forward the response to a payer and the payserver
exposes it too.
Closes https://github.com/spesmilo/electrum/issues/10176
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.
Fixes AttributeError when trying to get `num_sats_can_receive()` in
wallets without lnworker. Fixes https://github.com/spesmilo/electrum/issues/8100#issuecomment-3294556043.
```
Traceback (most recent call last):
File "/usr/lib/python3.13/site-packages/electrum/gui/qt/request_list.py", line 103, in selection_changed
self.receive_tab.update_current_request()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/electrum/gui/qt/receive_tab.py", line 237, in update_current_request
help_texts = self.wallet.get_help_texts_for_receive_request(req)
File "/usr/lib/python3.13/site-packages/electrum/wallet.py", line 3446, in get_help_texts_for_receive_request
can_receive = self.lnworker.num_sats_can_receive()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'num_sats_can_receive'
```
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.
Also suggest a submarine swap if the user creates a 0 amount invoice and
has 0 sat incoming liquidity as it won't be possible to receive
anything.
Users potentially just open a channel, then want to create a lightning invoice
without amount like they are used to from onchain addresses, and then
wonder why receiving doesn't work. So we should at least propose a swap
if there is no inbound liquidity at all.
closes https://github.com/spesmilo/electrum/issues/10119
also:
- wallet.get_onchain_history was broken with from_height/to_height args
- "show_fees" param is and was non-existent. fees are always added to output
- MyEncoder(json.JSONEncoder) changed a bit:
- I am pretty sure cutting the last 3 chars was intended to cut off the seconds
- however that was making incorrect assumptions about what datetime.isoformat() returns
- which depends on whether microsecond precision is available or whether an explicit timezone is set
- this now makes it clear that we want minutes-resolution, but still leaves the timezone-ambiguity
Adapts the gui(s) to detect if an existing reserve input has not been
used as input for the transaction even though the user tried to spend
max. This allows to show the lightning reserve warning not only for
reserve change outputs but also for existing reserve inputs that have
been ignored for this max spend transaction.
Still keeps the `is_utxo_reserve` flag on `PartialTxOutput` as it is
used in the qml gui.
Right now if a ln reserve is required and there is already a reserve
sized utxo available, `make_unsigned_transaction()` will still add the
reserve as input to a 'spend max' transaction and add a reserve change
output. This seems wasteful, this patch instead just removes the input
so it is not spent at all.
Watching-only wallets can have a keystore.
It was actually keystore.may_have_password() that was filtering them out but that was not really obvious.
Better to be explicit I think.
ThomasV