Often when the wallet creates a tx, the flow is:
- create unsigned tx
- sign tx
- broadcast tx, but don't save it in history
- server sends notification that status of a subscribed address changed
- client calls scripthash.get_history
- client sees txid in scripthash.get_history response
- client calls blockchain.transaction.get to request missing tx
Instead, now when we broadcast a tx on an interface, we cache that tx *for that interface*,
and just before calling blockchain.transaction.get, we lookup in the cache.
Hence this will often save a network request.
functools.lru_cache in the stdlib is not generic enough. That can be used to cache the results of a single pure function,
however I have usecases where one function is supposed to populate the cache, while another function consumes it.
https://docs.python.org/3/library/functools.html#functools.lru_cache
This is stripped down and extracts just the LRUCache from tkem/cachetools. It is relatively short, and very mature code.
I don't expect that we have to "follow" upstream, etc. There likely won't be relevant changes upstream.
Effectively, we are forking and bundling this code.
similar to 04582cc353
Handles exceptions thrown by `shutil.copyfile()` in the
`add_plugin_dialog`.
In issue #10101 an user tried to access an onedrive vault directory which
made shutil fail to copy the file with:
```
OSError: [Errno 22] Invalid argument: 'odopen://unlockvault/?accounttype=personal'
```
- minrelayfee is still server-reported, but the clamps are changed from [1, 50] to [0.1, 50] sat/vbyte
- dynamic feerates coming from the estimator are still clamped to [1, 1500] sat/vbyte
ref https://github.com/bitcoin/bitcoin/pull/33106
- the dust threshold in bitcoin core is calculated with a 3 sat/vbyte feerate,
which we were interpreting as 3*minrelayfee
- and now bitcoin core is considering changing the minrelayfee (1->0.1 s/b),
independently from the dust threshold
(in https://github.com/bitcoin/bitcoin/pull/33106)
so that with a feerate of 0.1 sat/vbyte, for a tx of size 141 vbytes, the fee is 15 sat (instead of 14 sat)
(assuming a min relay fee of 0.1 s/b, the tx needs to pay a minimum of 15 sats to propagate)
Adds `max_cltv` and `max_fee_msat` parameters to the `lnpay` cli command which allow to
specify the maximum total locktime of the payment and the maximum
absolute fee budget. This is enabled by
constructing a custom `PaymentFeeBudget` object in the lnpay command and
passing it as argument to `LNWallet.pay_invoice()`.
Allowing to specify a `max_cltv` value can be useful for certain
usecases, e.g. see https://github.com/spesmilo/electrum/issues/10056.
Closes#10056
adds unittest to `test_wallet_vertical.py` to verify it is not using the
existing ln reserve utxo as tx input if a reserve is still required (in
opposite to using it as input and creating a new reserve as output).
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.
