Adds the mutinynet signet (https://github.com/MutinyWallet/mutiny-net/)
to the supported networks so it's possible to
use it with Electrum. Mutinynet is similar to signet, except for a
shorter block interval (30 sec), a nice faucet
(faucet.mutinynet.com) and some extra features in its core fork.
It also has some lightning network nodes, see
the mempool instance on mutinynet.com.
Reduces the precision of the date field in the qml transaction history
list to minutes. Seconds don't seem very useful in practice and add
clutter to the UI. This adapts the behaviour to the Qt GUI.
When the user has already loaded a wallet in QML and tries to restore a
new wallet `WCHaveSeed.qml` incorrectly shows a `Finish` button instead
of a `Next` button and raises a KeyError if the user clicks on Finish
instead of resolving the passphrase input view (regression from
https://github.com/spesmilo/electrum/pull/10016).
This happens because `last` of `have_seed` depends on
`NewWalletWizard.is_single_password()` and NewWalletWizard.wants_ext(wizard_data).
`is_single_password()` is true if a wallet is already loaded,
while `wants_ext(wizard_data)` is false as `wants_ext()` depends on `seed_extend: True` in
`wizard_data` which only gets set after `apply()` of `WCHaveSeed` gets
called, however the evaluation of `WCHaveSeed` being the last view
happens before the view is shown.
By calling `checkIsLast()` in the validation timer of `WCHaveSeed` the
`last` property gets set again after `apply()` has been called, so
the view is guaranteed to correctly show either the `Finish` or `Next` button
after a seed has been entered.
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
