Also update existing key with some signatures.
Now both keys have ThomasV's sig,
and they cross-sign each other.
I will use sombernight_releasekey to sign releases, and keep using the
older key to sign commits and other day to day stuff. As I use a separate
key to sign commits, the release key can be made hard to get to.
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.
Previously if the wallet did not have a deterministic node id,
the wallet info dialog could say "lightning enabled, non-recoverable channels", but
the "recoverable channels" setting could be toggled and might even say "yes".
* Remove check for sign with privkey in init_cmdline
* Add with_privkey and with_wallet variants of signtransaction command
* Add unit tests for signtransaction_with_privkey and signtransaction_with_wallet commands
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