Fixes: after adding a payment request, if the process was killed,
the payreq might get lost. In case of using the GUI, neither the
callee nor the caller called wallet.save_db().
Unclear where wallet.save_db() should be called...
Now each method tries to persist their changes by default,
but as an optimisation, the caller can pass write_to_disk=False
e.g. when calling multiple such methods and then call wallet.save_db() itself.
If we had partial writes, which would either rm the need for wallet.save_db()
or at least make it cheaper, this code might get simpler...
related: https://github.com/spesmilo/electrum/pull/6435
related: https://github.com/spesmilo/electrum/issues/4823
Imported wallets used to send change back to the "from address".
We keep this behaviour as default.
There has already been an option "Use change addresses" (exposed in GUI),
ignored so far by imported wallets (was only used by HD wallets).
With this change, imported wallets no longer ignore that option, and if set,
they will send change to a random unused imported address, instead of back to "from address".
If all addresses are used, it falls back to sending change back to the "from address".
see: https://github.com/spesmilo/electrum/pull/7330
see: https://github.com/spesmilo/electrum/issues/5353
Re get_change_addresses_for_new_transaction,
"allow_reuse" is a confusing parameter name:
it means whether we allow reusing already used change addresses to send new change to.
However, if the method returns [], we will instead reuse the "from address" and send change there.
So it quite unclear without thinking it through what "allow_reuse" means as it could be either
of the two (and they are ~opposite scenarios).
The new name is long but at least it is clear.
This is a regression from 64a931f21e,
which introduced "onchain_channel_backups", and renamed
the old "channel_backups" key to "imported_channel_backups".
The `save_backup` method was not changed to use the new "imported_channel_backups" key,
so the channel backups are in the backup file but they are ignored.
The "Batch RBF transactions" feature mutates existing "local" and "unconfirmed RBF"
transactions when creating new transactions: it simply adds the new outputs to the
existing txs (and updates the change).
The "RBF" flag is only enforced for unconfirmed txs, not for local txs.
The bug was that given a local LN funding tx, when creating a new channel
with "batch_rbf" enabled, we would modify the existing local tx, and
broadcast that.
related: #7298
- use_recoverable_channel is a user setting, available
only in standard wallets with a 'segwit' seed_type
- if enabled, 'lightning_xprv' is derived from seed
- otherwise, wallets use the existing 'lightning_privkey2'
Recoverable channels:
- channel recovery data is added funding tx using an OP_RETURN
- recovery data = 4 magic bytes + node id[0:16]
- recovery data is chacha20 encrypted using funding_address as nonce.
(this will allow to fund multiple channels in the same tx)
GUI:
- whether channels are recoverable is shown in wallet info dialog.
- if the wallet can have recoverable channels but has an old node_id,
users are told to close their channels and restore from seed
to have that feature.
- Rename bump_fee "methods" to "strategies".
- Refactor strategies so that bump_fee can use any subset of them in any permutation.
- Adds a new strategy which decreases the payment outputs (instead of change).
Exclude unconfirmed transactions from --to_height and include them into --from_height.
The reason being that an unconfirmed transaction will end up eventually into the last
block which most of the time will be higher than --from_height
bump_fee was returning an invalid tx if its input was a
PartialTransaction that had signatures. It was relying on
line 1441 to remove signatures.
Relatedly, the WalletDB used to store such PartialTransactions as
PartialTransaction objects, but only until the program was restarted.
This is because serialising and de-serialising such a tx results in a
Transaction object.
So, combining these two, to reproduce a bug:
- create a tx, sign it, save as local
- bump fee, sign it, save as local
- bump fee --> tx already signed!? --> has old sigs, so it is invalid
Previously, if bump_fee decided to add new inputs to the tx, they would
have a different sequence number than the existing inputs. This was
unintentional.
