Backports from the GUI repo:
- bitcoin-core/gui#555
- bitcoin-core/gui#568
Backports from the GUI repo:
This commit does not change behavior.
Review hint:
git show --color-moved --color-moved-ws=allow-indentation-change
Github-Pull: bitcoin-core/gui#555
Rebased-From: 026b5b4523317fdefc69cf5cec55f76f18ad0c0a
Does not change behavior.
Review hint:
git show --color-moved --color-moved-ws=allow-indentation-change
Github-Pull: bitcoin-core/gui#555
Rebased-From: 4b5a6cd14967b8ec3cb525e4cb18628de6c15091
Before this change the send confirmation dialog would keep the Send option disabled. The Create Unsigned choice would actually send. This is potentially confusing.
With this change the Create Unsigned button will not attempt to sign and always produce a PSBT. The Send button will attempt to sign, and only return a PSBT if more signatures are needed.
When using an external signer, the Create Unsigned option only appears when PSBT controls are enabled in the wallet settings.
This commit maintains the pre-existing behavior of filling the PSBT (without signing) even when not using an external signer.
Closes #551
Co-authored-by: Jon Atack <jon@atack.com>
Github-Pull: bitcoin-core/gui#555
Rebased-From: 2efdfb88aab6496dcf2b98e0de30635bc6bade85
Approach NACK. This should just be a merge of the exact same commits/PR; it doesn’t need a separate cherry-pick.
As usual, the backport.py
script was used to prepare this PR.
I guess a new merge commit, rather than cherry-picking, has the benefit of preserving my commit signatures.
I don’t know how easy it is to implement that in the backport script. I could also make a cherry-pick PR myself :-)
As usual, the backport.py script was used to prepare this PR.
Point is, that’s not needed (and therefore shouldn’t be used) for this PR.
If the user has unchecked "Allow incoming connections" in
`Settings->Options...->Network` then `fListen=false` is saved in
`~/.config/Bitcoin/Bitcoin-Qt.conf`. This flips `-listen` to `false`
during startup, but leaves `-listenonion` to `true`.
This flipping of `-listen` is done in `OptionsModel::Init()` after
`InitParameterInteraction()` has been executed which would have flipped
`-listenonion`, should it have seen `-listen` being `false`
(this is a difference between `bitcoind` and `bitcoin-qt`).
Fixes: https://github.com/bitcoin-core/gui/issues/567
Github-Pull: bitcoin-core/gui#568
Rebased-From: 7f90dc26c8938f348938929b6d8bf1ea6f149209
git
perspective) to not cherry-pick unless required, but I don’t think this is reason enough to NACK this pull, since there won’t be any difference for end-users (except for the git hash that is embedded in the binary).
git
commands would create such a merge? There are intermediate, undesired, commits in master
, a merge would drag them into 23.x
too.