Toggle chain from menu (using Settings) #414

Implements #78

It's currently not easy for GUI users to switch to a test chain like signet. E.g on macOS this requires using the command line, since Spotlight doesn't let you add an argument like -signet.

This PR makes it easier by adding a menu option to restart with a different chain. ~It does this by adding a .chain_gui file. Unfortunately we can't use settings.json, because this file is network specific. This file is ignored by bitcoind.~ It does this by adding chain to the mainnet QSettings.

<img width="445" alt="Schermafbeelding 2021-09-01 om 13 01 37" src="https://user-images.githubusercontent.com/10217/131660689-40dc89b4-bafc-4e11-b75c-254584b43ff2.png"> (it's now under Settings, not File)

I think you could just use QSettings for this, the same way the GUI datadir preference and all other other GUI-only settings are stored in QSettings. Even https://github.com/bitcoin/bitcoin/pull/15936 which consolidates bitcoin-qt and bitcoind settings in settings.json still stores GUI-only settings in QSettings.

I guess thinking more generally, for example if we did want to add a changenetwork RPC that would save a different network preference and restart, I'd probably do that by adding support for reading the -chain setting from the top level settings.json file, and then having bitcoind and bitcoin-qt both use this value at startup to choose the network and locate network-specific data and network-specific settings file from there. This would maybe be a little more complicated to implement than the QSettings or .chain_gui approaches, but probably not too bad.

I guess my preference would be to take this general approach and store the network preference in the chain field of the the top level settings.json. Or if that is too much work to implement, store it in QSettings. Or if that is not worth the effort either, keep this new .chain_gui file.

No matter which location is chosen, it could in theory be migrated somewhere else later, but migrating would be at least a little messy and could create edge cases when downgrading, so it is good to put a little effort into choosing the best location now.

If we're keeping some QSettings around anyway, I might as well use that. With bitcoind it's trivial to just specify the network as a parameter.

I switched to using QSettings. Similar to settings.json these are also network dependent. The GUI does this by changing its name during the bootstrap process, right after deciding which chain its on (step 7).

This PR uses the same trick in reverse: it changes the application name back to mainnet right before updating the chain setting, and then quits.

Concept ACK

This PR adds the functionality to select a network chain directly from the GUI, making it easier to toggle between the chains. This is achieved by adding a context menu option to set the -chain suboption to the selected chain type and closing the GUI. So that when next time GUI will start, the value of -chain suboption will by default be set to the last selected network by the user. This value, as I observed, can always be overridden while opening the bitcoin GUI through the command line.

Tested the PR on Ubuntu 20.04. The PR works as described by OP. I am adding the screenshot of the added context menu options.

This PR also has a byproduct benefit that is not discussed till now. For a person like me who mainly works on a signet network, I do not have to explicitly create an alias or select the signet chain each time I want to open GUI. So that’s great!

I have a few suggestions I want to put forward that might further improve the PR:

• Before line 459:

QMessageBox::StandardButton btnRetVal = QMessageBox::question(this, tr("Confirm chain"),

Add translator’s comment for text in the StandardButton.

• Add mnemonic shortcuts for the added context menu options.
• It would be great if the GUI could automatically start after toggling the chain instead of simply closing the app.

@ShaMan239 thanks for the review! I added a translator hint and keyboard shortcuts (I can't test those on macOS, new screenshot is welcome). Unfortunately afaik Bitcoin Core can't restart itself. This is a problem with some settings changes too.

The Translator’s comments look good. Regarding the mnemonics shortcuts, there are some collisions between them.

Load PSBT from &clipboard <-> Switch &chain

&Backup wallet <-> &Bitcoin

Unfortunately, afaik Bitcoin Core can't restart itself.

Well, that’s a bummer. I was just wondering if this feature could be added and would that even be worth adding.

Maybe I misunderstand how these shortcuts work... Wouldn't "c" take you to the chain submenu and then "b" to Bitcoin inside that menu? Or all the shortcuts global?

Approach ACK, makes sense to have this separate from other options.

Tested ACK 79af0d657bc080bfd78b70a968c50f654c1aa329.

Also added the check on the current chain to better indicate why the current is disabled.

with the following

+            const bool is_current = gArgs.GetChainName() == chain.first.toStdString();
             QAction* action = m_chain_selection_menu->addAction(chain.second);
-
-            if (gArgs.GetChainName() == chain.first.toStdString()) {
-              action->setEnabled(false);
-            }
+            action->setCheckable(true);
+            action->setChecked(is_current);
+            action->setEnabled(!is_current);

Now I can't pick a different chain from the command line, for instance src/qt/bitcoin-qt -regtest gives Error: Invalid combination of -regtest, -signet, -testnet and -chain. Can use at most one..

@promag thanks, addressed comments and added the checkmark. Though on my machine I can't see the checkmark (QT 6.1.2 via homebrew).

Once you use the GUI to select a chain, there's no way back :-) Actually you can still use -chain=regtest. The error message is a bit confusing, it's just that you have to use either -chain= or use one of -regtest, -signet, -testnet, -main

The chain is a special case with so many weird rules, I'd rather not mess with:

https://github.com/bitcoin-core/gui/blob/f4e12fd50c23875f4b5f272c94449eb81de43d5d/src/util/settings.cpp#L129-L143

Code review ACK 246d0658b41b232151567356694c8580f32a800e.

Concept ACK.

1. Still having this error on Linux:

Now I can't pick a different chain from the command line, for instance src/qt/bitcoin-qt -regtest gives Error: Invalid combination of -regtest, -signet, -testnet and -chain. Can use at most one..

UPDATE:

Once you use the GUI to select a chain, there's no way back :-)

Maybe always add the chain value to settings at the first run the new code, and notify users about new behavior?

END OF UPDATE

2. It seems possible to move all new code from BitcoinGUI::createActions() to BitcoinGUI::createMenuBar() and use the local variable chain_selection_action instead of the data member m_chain_selection_action.

3. Why not add translator comments to all of the added tr() arguments?

Changes since my last review:

• The checkmark is added along with the options to emphasize which chain is currently selected. I think it makes sense to add a checkmark, so I agree with this change Adding screenshots of the visual change before and after updating PR.

Before Update	After Update

Maybe I misunderstand how these shortcuts work... Wouldn't "c" take you to the chain submenu and then "b" to Bitcoin inside that menu? Or all the shortcuts global?

I just checked if the shortcuts are global. They are not, and so I have updated my comment accordingly. But there is still the collision of mnemonics between Load PSBT from &clipboard and Switch &chain as they are part of the same menu. So I would recommend updating the mnemonics shortcut to &S

diff --git a/src/qt/bitcoingui.cpp b/src/qt/bitcoingui.cpp
index 39a58f4d1..5aedbbf43 100644
--- a/src/qt/bitcoingui.cpp
+++ b/src/qt/bitcoingui.cpp
@@ -441,7 +441,7 @@ void BitcoinGUI::createActions()
     }
 #endif // ENABLE_WALLET
 
-    m_chain_selection_action = new QAction(tr("Switch &chain"), this);
+    m_chain_selection_action = new QAction(tr("&Switch chain"), this);
     m_chain_selection_action->setStatusTip(tr("Restart application using a different (test) network"));
     m_chain_selection_menu = new QMenu(this);

Maybe always add the chain value to settings at the first run the new code, and notify users about new behavior?

Done, and added a release note.

I moved the menu stuff to BitcoinGUI::createMenuBar()

Why not add translator comments to all of the added tr() arguments?

Done (I think).

I switched the shortcut to Switch &chain

tACK bc72b19 Tested on Ubuntu 20.04 (Using Qt version 5.12.8)

Updates since my last review:

• Release notes are added to inform users about the change in behavior in the way of using chain variables.
• GUI will open on the mainnet when the user specifies no specific chain, either through Command-Line or GUI.
• The scope of the chain_selction_menu variable has been changed from global to local. btnRetVal renamed to btn_ret_val according to the naming convention.
• The mnemonic shortcut of the switch chain option has been changed from &c to &S, removing shortcut collision.

I tested the updated PR on Ubuntu 20.04. The PR works perfectly. Also, I followed the release notes word by word while testing. They are correct too. The collision between mnemonic shortcuts has been resolved, and the new mnemonic shortcut is working perfectly.

I am adding the screenshot of the latest commit.

Thanks for this amazing work, @Sjors!

@kallewoof @ajtowns you might enjoy this PR

Concept NACK. I think there should be a very firm line between Bitcoin and test networks. Something like this can too easily lead to loss because someone forgot they switched back to mainnet.

Slightly agree with @luke-jr but I can see why it would be nice to have. Just not sure how often you switch between networks like that.

Maybe this should be a default-disabled feature that developers can turn on when compiling.

Concept NACK, agree with @luke-jr

After further consideration, I agree with @luke-jr. While this is a nice-to-have, without including several new UI/UX changes to prevent a user from footgunning; there's a possibility that this can do harm.

To be clear, I'm concept ACK on the general Idea, I think there's room for a feature like this. But, this should be done with careful attention and perhaps safeguarded, as mentioned by @kallewoof, behind an options menu-setting.

Something like this can too easily lead to loss because someone forgot they switched back to mainnet.

How? The addresses are different and incompatible. It seems to me that losing funds would require deception, not just forgetting something.

I'm happy to move this into the options dialog, but I don't see how that helps in the deception scenario. For that it might be more useful to add a stern warning.

Maybe this should be a default-disabled feature that developers can turn on when compiling.

The purpose of this PR is to make it practical for GUI users to use signet and testnet. Anyone who can self-compile can also just open a terminal and enter /Applications/Bitcoin\ Core.app/Contents/MacOS/Bitcoin-Qt -signet.

Being able to use signet and testnet lets users practice with (multisig) wallets without risking real funds. So you lose some safety in one place and gain it in another.

Also note that in Windows it's already possible to launch with a different network: #78 (comment)

This seems harmless, but why is not possible to have different icons on macos like we can have on windows or linux? Is this an operating system limitation? An installer limitation? Also why is it better to shut down the mainnet instance when you want to start a testnet instance? Would you want to shut down your main wallet while experimenting and trying something in your test wallet?

Mainnet and testnet just being separate apps with separate icons that can be started and stopped independently would seem like the ideal thing. How does Microsoft Office work on macos? Can you open Word and Powerpoint at the same time, or is there a menu where you switch from Word mode to Powerpoint mode?

possible to have different icons on macos like we can have on windows or linux?

I briefly looked into this. It wasn't obvious how to do it with the custom DMG generator script(s) we have. But it might be possible. However, macOS apps are installed through a drag and drop process, so we'd have to show 4 icons during the install phase. That seems potentially confusing. Another option would be to make them completely separate downloads, also confusing, and a bunch of extra guix signing.

We could completely revamp the installer into a wizard-like system that moves the binaries itself, rather than drag and drop. One advantage of that is that we can also put bitcoind and bitcoin-cli and the wallet tool in the right places (which are absent now). But that's a big change.

Also why is it better to shut down the mainnet instance when you want to start a testnet instance?

This is a side effect of the approach I use, by putting the network in the global settings you can't easily run multiple instances. Separate icons would solve that, but create new problems as I described above.

Another approach could be to always launch in mainnet, and keep that open, but allow the application to launch another instance of itself with e.g. -testnet. But launching apps from within an app might be a bit scary too.

Another approach could be to always launch in mainnet, and keep that open, but allow the application to launch another instance of itself with e.g. -testnet. But launching apps from within an app might be a bit scary too.

That sounds like it could potentially be a really confusing eventual .5 TB loss of disk space for users who think "regtest" means "regtest" and not "regtest with a slice of main net syncing in the background"..

The "document" approach seems sensible, i.e. where you "open" instances (main/test/sig/reg/custom) from within the application. Could be potentially really useful if you are doing multiple regtests and like doing things in the GUI.

@Sjors thx for PR. Please add support of custom private rpc for regtest.

Receiving this alert on MacOS

Process:               Bitcoin-Qt [46840]
Path:                  /Users/USER/*/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt
Identifier:            org.bitcoinfoundation.Bitcoin-Qt
Version:               22.99.0 (22.99.0)
Code Type:             X86-64 (Native)
Parent Process:        bash [79038]
Responsible:           Terminal [425]
User ID:               501

Date/Time:             2022-02-08 00:52:00.534 -0500
OS Version:            Mac OS X 10.15.7 (19H1615)
Report Version:        12
Anonymous UUID:        50406######################9E77F6

Sleep/Wake UUID:       E9EA##########################199E

Time Awake Since Boot: 96000 seconds
Time Since Wake:       95000 seconds

System Integrity Protection: disabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Cirrus: https://cirrus-ci.com/build/6466679780671488

Running Cirrus on PR: Cirrus: https://cirrus-ci.com/build/6466679780671488

Running Cirrus on the rebased branch: Rebase: https://cirrus-ci.com/build/4721486761033728

It seems that Switch chain belongs in the Settings menu: https://github.com/RandyMcMillan/gui/commit/9b1456cf59e4ee41a6a9ab4985b4716f231163fc https://cirrus-ci.com/build/4848117060206592

On a side note:

It could be argued that "FIle" is incorrect since mostly wallet operations are listed under this menu. The wallet related functions could be grouped together - with the other functions in a sub menu group. File could be changed to Wallet

@RandyMcMillan thanks for testing! That crash is worrying. I'm getting this too now some of the time. Inspired by #336 I changed QApplication::quit(); to Q_EMIT quitRequested();. That seems to fix it.

I also moved the menu to Settings. And rebased. @dlarchikov:

Please add support of custom private rpc for regtest.

I'm not sure what you mean by this.

I will retest shortly - this sounds like a much friendlier method of shutdown...

Approach ACK f3ddafa

MacOS (x86_64) is now receiving a gentle shutdown signal - removing the unexpected shutdown alert. This should be allowing the data directory to be in a good state upon restarting.

I will test MacOS ARM64 shortly.

Great Work @Sjors !

Thanks! I fixed the duplicate "ClientClient" string.

reACK Approach https://github.com/bitcoin-core/gui/commit/df3ad9a68ff84c01f62bfb49766da890f4be2c82

Tested on MacOS Arm64 - shutting down cleanly.

I have reservations about this feature, and also think the implementation could be improved, but code review ACK 12431e0d95157b4df18912b38735acdc927c9762 since I don't think there are problems with the code.

Code review comments below suggest ways to improve the implementation, and I also agree with luke-jr (https://github.com/bitcoin-core/gui/pull/414#issuecomment-923255521) and kalle and achow and jarolrod that in general this change could result in confusion and be a net negative. I mostly just don't think it makes sense from a user perspective that you are forced to shut down your connection and wallets for one network to connect to a different network, instead of just opening different networks in different windows. There's no problem doing this on Linux or Windows (IIUC from #78 (comment)) because Linux and Windows packages can provide separate icons for launching testnet and signet instances. Ideally the mac package would just provide separate icons as well so we wouldn't need this less flexible and potentially confusing toggle.

I don't see a technical reason why providing separate icons shouldn't be possible on mac. This guide about creating DMGs https://intmaker.com/deploy-to-macos/ has a section "Level 3: additional applications" about adding helper applications alongside the main application. In this case, helper applications could be Bitcoin-Qt (testnet) and Bitcoin-Qt (signet) scripts that call the main Bitcoin-Qt application with appropriate command line arguments. https://superuser.com/a/16777 shows how to write applescripts that invoke applications with command lines and https://apple.stackexchange.com/a/407885 shows how to package scripts as applications with icons.

Another approach would be to replace the "Switch Chain" toggle menu with an "Open Chain" menu, which would just open new windows connecting to other networks, instead of closing down the whole application and restarting. The implementation could still use QSettings to remember what windows are open so relaunching bitcoin will reopen the same windows (Or if every window was manually closed by the user, reopen the last closed window).

<!--cf906140f33d8803c4a75a2196329ecb-->

🐙 This pull request conflicts with the target branch and needs rebase.

_{Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".}

@ryanofsky thanks for all the comments, I'm a bit behind on things, but will get to them.

re: #414 (comment)

@ryanofsky thanks for all the comments, I'm a bit behind on things, but will get to them.

:+1:

Even though I suggested a lot of changes, I think this PR is ok in its current form. The other reviewers who objected to this PR previously should speak up if they still have issues with it, or if they think any changes would make it better. Sjors has already put a good amount of work into this, and some of the changes I suggested would require even more effort. So it'd be good to sync up and make sure effort is not wasted.

Concept reACK

If a custom signet is detected - It would be great to add a truncated "finger print" of the active signet_challenge - I have experimented with adding a signet challenge to the window title and menu and the string is simply too long - but a "finger print" will work in the window title. Maybe use a finger print with 8 chars?

examples:

1. BitcoinCore - [signet] [stuvwxyz] or
2. BitcoinCore - [signet] [...stuvwxyz] or
3. BitcoinCore - [signet] [abcd...wxyz]

Just an idea...but if this was added - option 3 seems best IMO.

Concept re-NACK.

How about for macOS only, a menu item that simply launches a separate instance on a test network?

What is the status of this PR?

@hebasto still on my list to look into some of the other approaches suggested above. But if anyone else wants to do it sooner, don't hesitate!

How about for macOS only, a menu item that simply launches a separate instance on a test network?

That would be fine by me, not sure if it requires adding dependencies to launch an application.

Closing this as it has not had any activity in a while. If you are interested in continuing work on this, please leave a comment so that it can be reopened.

But if anyone else wants to do it sooner, don't hesitate!

Will be labeled "Up for grabs".