Concept ACK. Not sure if the tab view is the best container for the send wizard. Have you considered back/next buttons?

I went back and for myself on the view style and ultimately did settle on a tab view. Ultimately there's never actually a need to press the Back and Next buttons unless you're doing something wrong (or a trivial demo) -- each step of the process will happen on a different machine.

I like the idea of a "load PSBT" menu item taking you to the right tab. In my implementation, there is an "offline" menu from which you have to select "sign" or "broadcast" to open the dialog to the right tab; then you load from there.

There's a lot of stuff that came up in the process of implementing this which I don't know if you've run into yet. For example, the signing wallet may not be able to put up the usual form of the confirmation display, as shown here, unless it has some trustworthy way to know which output is change, which it doesn't except maybe if you're using descriptors to tell it so.

Jumping back to Draft, much like having back/next buttons, is probably mostly not going to get used in real life, where the signing is happening on a different machine from the drafting. Honestly I think the main reason to have the steps of this flow be one dialog are to help the user have a sense of their place in the process, even though I expect probably they will be mostly used separately and on separate machines.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17219 (wallet: allow transaction without change if keypool is empty by Sjors)
• #17165 (Remove BIP70 support by fanquake)
• #17154 (wallet: Remove return value from CommitTransaction by jnewbery)
• #16944 (gui: create PSBT with watch-only wallet by Sjors)
• #16876 (gui: Drop calls to QCoreApplication::processEvents by promag)
• #16710 (build: Enable -Wsuggest-override if available by hebasto)
• #16341 (Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

the signing wallet may not be able to put up the usual form of the confirmation display, as shown here, unless it has some trustworthy way to know which output is change, which it doesn't except maybe if you're using descriptors to tell it so.

I have a hardware wallet GUI PR #16549 which is built on top of native descriptor wallets #16528.

I'm also thinking of replacing WalletModelTransction, which is a QT-only thing, with PSBT. But perhaps that's better for a followup.

Re tab view: I briefly looked at QWizard but that doesn't give the user an overview of where they are in the flow. The good news is that QTabWidget can easily be swapped with QStackedWidget which can be completely customized, e.g. into something like this:

I'll probably disable the other tabs, so that all "navigation" happens through the buttons at the bottom of the screen.

I expect probably they will be mostly used separately and on separate machines

I'm thinking more of the hardware wallet use case. In the simplest configuration of 1 hardware wallet that's physically connected, the Sign tab is a nice place to show it. In case of something like ColdCard or the new BitBox this is where you would save the unsigned PSBT to SD drive.

Added RBF. If a followup PR splits fee selection out of Tab 1 then bump fee could also support a custom amount, rather the current take it or leave it fee.

I'm considering squashing this into a single commit; current commit history is probably more confusing than useful.

Concept ACK

Concept NACK. Sorry, this looks ugly, much worse than the current flow.

(Also, normal users probably shouldn't see txids...)

That's subjective. I think it looks better, because it's less cluttered and gets rid of a popup. Happy to hide the transaction id.

The current sign screen (which is a popup) doesn't have space to list hardware wallets. There's also not much room for PSBT creation and/or signing, other than just magically putting it on a clipboard (see #16944). If you have a better design I'd love to see it.

If you have a better design I'd love to see it.

To be clear, I think the current design with popup is better...

This frees up UI real estate where we can add support for PSBT, hardware wallets and education.

Concept ACK on motivation for this. I don't have a view on its ugliness. For these UI redesigns it seems totally dependent on the regular users of the GUI. Personally I support the goal of the GUI being an educational stepping stone to using the CLI. There will be always be better GUIs for the non technically curious which aren't subject to the constraints of Core.

My view is almost entirely the opposite: The JSON-RPC server isn't meant for end users, but for software developers to interface with. The GUI is the primary method for end users to use Bitcoin Core, not some mere "stepping stone" to a half-baked JSON-RPC client...

P.S. In addition to being a developer, I am a regular user of the GUI.

I think @michaelfolkson was referring to having independently developed wallet applications that use the RPC (somewhat limited atm) or IPC (#10102). I use the GUI as well.

I'm not entirely sure who this GUI is being designed for. Long time contributors like Sjors, Luke? Complete Bitcoin beginners? Someone like me who is technically curious and would ideally want to transition from any reliance on the GUI? All of us? (fiendishly difficult as you are making design compromises all over the place).

If it is complete Bitcoin beginners then none of us are the target audience. But this is a meta point and this discussion has probably been rehashed multiple times over the years so I won't clog up this PR with it.

I've opened an issue #17395. I don't want to derail review of this particular PR.

Concept NACK. Sorry, this looks ugly, much worse than the current flow
To be clear, I think the current design with popup is better...

What current design allows you to generate PSBT's from the GUI of offline versions of Bitcoin Core for secure multisig? AFAIK, #16944, #16954, and this PR are the only discussions/PRs around this (#16546, #16549, and #16895 for HWWs).

The UI isn't beautiful (neither is the rest of Core), but it's not ugly. And I don't believe that's the point, especially from reading #17395, that seems to be the consensus. The point is to be secure, power-user friendly, and mistake-minimizing.

And I don't believe that's the point, especially from reading #17395, that seems to be the consensus. The point is to be secure, power-user friendly, and mistake-minimizing.

Do you agree with that @luke-jr? Feel free to comment on #17395 if you do/don't.

Closing this in favor of more incremental changes, e.g. #17509.