bitcoin-core / gui Goto Github PK

Having tray icons that communicate more clearly the status of your bitcoin node is something I think would be a minor UX improvement. Below I've proposed three states.

Solid green = Network is fully syncd with most recent block.

Flashing green = Syncing with the Bitcoin network.

Solid red = Network has connectivity issues and is not syncing

Figma File

While investigating #32 I found a buggy (?) behavior of QFileDialog.

From the Qt docs:

By default, a platform-native file dialog will be used if the platform has one.

When Qt and QPA plugin are dynamic linked:

$ ./src/qt/bitcoin-qt -printtoconsole
2020-07-15T09:15:39Z [main] Bitcoin Core version v0.20.0 (release build)
2020-07-15T09:15:39Z [main] Qt 5.12.8 (dynamic), plugin=xcb (dynamic)

QFileDialog works as expected, and uses a platform-native file dialog.

When Qt and QPA plugin are static linked (gitian builds):

$ /home/hebasto/bitcoin-0.20.0/bin/bitcoin-qt -printtoconsole
2020-07-15T09:07:04Z Bitcoin Core version v0.20.0 (release build)
2020-07-15T09:07:04Z Qt 5.9.8 (static), plugin=xcb (static)

QFileDialog fails to recognize the platform, and uses a widget-based implementation.

Even running with QT_QPA_PLATFORM=xcb doesn't help.

Ported from bitcoin/bitcoin#18537.

When running bitcoin qt over x11 remote session (DISPLAY=1.2.3.4:0) in a clean machine, wallet stops with error.

Expected behavior

Initial intro dialog (were to put the data files) opened.

Actual behavior

I got this:

The X11 connection broke: Maximum allowed requested length exceeded (code 4)
XIO:  fatal IO error 2 (No such file or directory) on X server "192.168.200.26:51"
      after 219 requests (219 known processed) with 0 events remaining.

To reproduce

Need a clean machine (~/.bitcoin sould be not exists), need a remote x11 "desktop".

export DISPLAY=1.2.3.4:0
./bitcoin-qt

System information

ubuntu bionic/xenial tested
x64/arm cpu tested
remote x11 session: xvnc and pure xorg tested

The issue

Intro dialog sets the windowicon, this bitmap is 1024x1024 pixels. the qt5 convert this into argb32 format (=1 pixel 4 bytes), thats 4M data. The x11 remote connections allow only less than 4M length.

Possible fix

We dont need 1024x1024 dialog icon, just 128x128 or 256x256. So scale the icon:

intro.setWindowIcon(QIcon(QPixmap(":icons/bitcoin").scaled(QSize(128, 128), Qt::KeepAspectRatio, Qt::SmoothTransformation )));

Ci should be active in this repo as well

Moved from bitcoin/bitcoin#16000.

The generate method has been removed from Bitcoin Core, but it would be nice if the GUI had a generate method in the debug console. That method would effectively expand to generatetoaddress(getnewaddress()) (just like the def generate in our test node python class)

Moved from: bitcoin/bitcoin#19103.

Somehow the resolution of the QRCode image is not high enough.
Native wpkh addresses are non readable and legacy/p2sh addresses are not good readable.
Haven't tested on other OSes than macOS.

Moved from bitcoin/bitcoin#15008.

When a valid address is entered/pasted in the "Pay To" field and it belongs to a loaded wallet then it could note that.

Had the idea after bitcoin/bitcoin#12688.

Steps to reproduce:
disconnect a full indexed node that has no "wallets" dir, in -datadir. and all node files in -datadir
wait until you missed say 20 or more new blocks.
A fast syncing high bandwide node might need a lag of more than 100
....
start the node with ui.
wait until IBD had set in..
click [Open Wallet] ....

If your whole system or VM ui enters an unresponsive state,
Don;t panic, brew a tee !!!. System should leave dead lock after < 5 min.
Close ui., hmm... 🤷‍♀️
In essence that is an edge case, but new users who first time try to do the right thing and run there full nodes
might run in this ...

refernced bitcoin/bitcoin#19419

EDIT: Note: even that fixed, the other freeze of window refresh, if re-scanning a wallet lag;s behind, is a different gui issue.to be solved in pipeline. ...
Upwards v0.18 ,19. 20 release to master you could get ui also in local temporary freeze, with -reindex or mine more than say 3117 blocks on a different node to an address of your test node and than connect to that mining node.
Unless you have a spared miner or to much btc, the preferred method to test is with regtest.

a="/tmp/test_a"
b="/tmp/test_b"
ca="-regtest -datadir=$a"
cb="-regtest -datadir=$b"
mkdir $a
mkdir $b
bitcoind -daemon $ca -server -datadir=$a
sleep 1
adr=$(bitcoin-cli  $ca getnewaddress) 
echo $adr
bitcoin-cli $ca stop 
sleep 1
bitcoin-qt  $cb  -server -listen  -datadir=$b &
sleep 1
echo "wait for coins ... this could take some while to gen"
gen=$(bitcoin-cli $cb generatetoaddress 3117  $adr) 
# Now start the node, should instant frezze repaint update
bitcoin-qt  $ca -connect=127.0.0.1 -port=1234 -datadir=$a &
echo $gen

////
frezze b ?

  

So far observed in debian and lubuntu VM's

Is your feature request related to a problem? Please describe.

• bitcoin.conf file is used by lot of users with different settings
• any malware can modify this file which can affect bitcoin core wallet
• if the user is unaware of changes made by someone else in bitcoin.conf, it may affect UX, privacy and maybe security

Describe the solution you'd like

• user should be notified if the file was changed when wallet is loading

Describe alternatives you've considered

• maybe user can keep his system secure and bitcoin core related files however the solution I suggested is basic information about file modification time and changes nothing much related to how wallet works

Additional context
Maybe we can add text below "The Bitcoin Core Developers" to display such information

bitcoin/bitcoin#17509 introduces a Load PSBT menu option. It would be even easier if a user can double-click on a PSBT file, open it from an email, etc. For this we would need to register a file handler.

This can be done by defining a QAbstractFileEngineHandler for .psbt files, which should then call the same code as "File" -> "Load PSBT".

One potential downside of a file handler, is that it encourages users to double-click on potentially untrusted files, which might be nasty executables.

This is in regards to bitcoin/bitcoin#15450

If you check 'Disable Private Keys', is that not initially a Blank Wallet, until you import an xpub?
I don't understand what the difference would be between checking just 'Disable Private Keys', and checking 'Disable Private Keys' and 'Make Blank Wallet'.

Should checking 'Disable Private Keys' automatically check 'Make Blank Wallet'? (But not vice versa - Making a Blank Wallet with/without Disabling Private Keys affects the future ability to import.)

But then I am concerned that this would be very confusing for the end user. Enabling 'Encrypt Wallet' already disables 'Disable Private Keys'.

Here are 4 different application windows with different actions for closing the windows. Sometimes it says 'Close', sometimes 'OK'. All times there is a native OS close option.

Personally, I think less is more, and you can just get rid of them all together and just let the user use the native OS windowing [X] to close them. Reduce decision fatigue with fewer options to consider and a cleaner UI.

Filing this one as a more formal issue as per a conversation with @achow101 on Twitter. To recap:

There is strong public advocacy to 'Run your own node' for all the obvious reasons. And many say the easiest way to do that today is 'just download/install core.' Fair enough. But for a new user, that is not what appears to be taking place when you actually install Core. Instead, the UI you are presented with is a wallet. But even that's not completely obvious. What you are presented with in the most prominent position is the "Overview" panel.

Overview of what? Of the Node I believe I just installed? No. It's actually an Overview of the default wallet that gets created for you.

It would seem that based on the current UI, there should be something that makes it more obvious that you are looking at a Wallet. As you can see in the Twitter thread, my initial suggestion is to modify the application title bar to something like: "Bitcoin Core - Default Wallet" This at least establishes a more accurate hierarchy with the current Wallet as the parent container, with the child-elements of Overview, Send, Receive, Transactions as actions specific to the current Wallet.

However that still doesn't address the fact that the Node I was told to install isn't anywhere to be seen. In fact, as far as I can tell, you access Node functionality from the Window menu > Console. Which opens up a Node window that has a few Node-related tabs.

One could certainly push back on all this and make the argument that those loudly pushing the 'Run your own node' narrative could be causing the confusion instead of the UI of Core. Or Core could adapt to that predominant narrative and work to design a UI that clearly delineates the Node and Wallet elements. Up for debate! :)

Expected behavior
For it to work

For a new wallet to be created
Actual behavior
an error msg: "A fatal error occurred. Bitcoin can no longer continue safely and will quit."

bitcoin-core.qt 
************************
EXCEPTION: N5boost10filesystem16filesystem_errorE       
boost::filesystem::create_directory: Permission denied: "/mnt/2c094727-1118-4a5b-ab85-2169901da8e9/bitcoin/blocks"       
bitcoin in Runaway exception       


**To reproduce**
run bitcoin-core.qt from terminal

**System information**
Ubuntu 19.10
<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->
snap store
<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->
6TB hard drive
<!-- GUI-related issue? What is your operating system and its version? If Linux, what is your desktop environment and graphical shell? -->
ubuntu-wayland

This is a thread for general meta questions and feedback regarding this repo

Ported from: bitcoin/bitcoin#17047.

There are, for now, 4 languages which are not displayed in the windows/linux qt language list. I am not sure about macOS.

These languages are:
Esperanto, Latin, Silesian and Kapampangan.

Side note: My windows machine has the options to switch to Esperanto and Silesian languages, so they do "exist" somewhere in Windows.

Kurdish is also not displayed (correctly?), but I'm not sure if that's only a font issue or not.

QT fetches language names from OS itself, unless otherwise specified. Some info here.
I tried to fix this issue with bitcoin/bitcoin#16808.

On the image: Esperanto name not displayed - (eo).

I'd like to continue the discussion from #17395 over at the bitcoin repo started by @michaelfolkson.

The two questions posed by Michael a long with summarized replies from the original thread are below. As someone who is interested in contributing to the design of the GUI I've also included some of my own opinions throughout.

1. Who are we designing the GUI for? Long term Core contributors (highly technical) that use the GUI on a regular basis? I don't know how many of these there are. Technically curious who use the GUI when they can't work out how to do something from the command line? Complete Bitcoin beginners? All of these groups? If it is the latter then we should all be under no illusions that compromises are necessary which will mean it is impossible for the design to be optimal for an individual group.

2. Design preferences are subject to the "sample size of 1" trap where those reviewing GUI changes think they are providing feedback on behalf of a group that they don't belong to. A highly technical user just does not know what is optimal for a beginner. The only way you see what is optimal for a beginner is putting alternative GUIs in the hands of a statistically significant group of beginners.

• The GUI is intended for 'power users,' not beginners, intermediate or devs. Power users being those who are technically competent to run their own node, have basic CLI skills, but are still more comfortable with a simpler UI.

I think devs also fall within the user base albeit not as frequent as the power users (say if the dev wants to do a simple task in a few clicks). Over time and with good design we can include all users (see below).

• In the future the GUI should also include beginners and intermediate users, although not at the expense of removing important features or negatively impacting security, privacy, control etc.

I don't see this as an issue as good design should be able to cater to both experienced and inexperienced users. As an example see this exchange which offers different interfaces for differing user skills - taken from crypto UX handbook. Good usability is synonymous with good security - Casa articulates this much better in their wealth security protocol.

• The GUI does not need to be flashy / modern looking.

I agree with this but this is in many ways unrelated to good design. A flashy look can increase usability is not synonymous with Aesthetics. As long as its fulfills its job thats all the matters. At this stage that job being having any level of user being able to run a node and have a wallet attached to that node (whether wallet features are used in the GUI or

• Designers need to work within the constraints of Qt.

Good point to make but I don't think the constraints are as big as made out to be in the original thread. As Christoph Ono, who worked on the designs for the Monero GUI which also uses Qt, pointed out a small team managed to revamp the UI/UX of the GUI over a few years without too many issues, see here. @GBKS

• Having a modular GUI / multiple implementations to cater to different user bases.

As I mentioned above I think good design can cater to all audiences within the same app, having a modular GUI is not an efficient way to go about things in my opinion.

• What is the main purpose of the GUI? "Note that the GUI is needed for more than just the wallet... right now, it is the only realistic way for a normal end user to run their own node at all." @luke-jr

Luke also mentions "...Bitcoin's security depends on a super-majority of the economy using their own full node." This isn't possible without including beginner and intermediate users which can only be done through well articulated design.

Although this will likely be a controversial take, is the discontinuation of the GUI once enough options exist outside of core for users to run a fully validating node an option? Projects such as Umbrel and myNode are good examples of non-GUI fully validating nodes. If these become more popular among users for running a node than the GUI, is the resources put into it worthwhile when they could be applied to making bitcoins foundations even stronger?

• Many usability improvements are being worked on on the technical side - 1 2 3

With initiatives such as Bitcoin Design and square crypto design grants on offer, many more designers are likely to start contributing to open source bitcoin projects like the GUI. It's important that discussions like this happen so that designers and devs are on the same page.

I'd encourage devs to join the bitcoin design slack and for designers to frequent this repo and join in on discussions when they can.

Currently the test_bitcoin-qt unit test uses the standard regtest port. It will fail to start if something else is using the regtest port, like a regtest instance of bitcoind or bitcoin-qt. Or another running test_bitcoin-qt (this happens if you are updating multiple branches at the same time). Instead of using the standard regtest port, this unit test should be using a random free port like we do in the functional tests.

Want to work on this issue?

For guidance on contributing, please read CONTRIBUTING.md before opening your pull request.

After the initial install there is an overlay that provides a description and progress of syncing. If a user clicks on the main UI buttons (Overview, Send, Receive, Transactions) while that overlay is visible, nothing seems to happen. The buttons respond as if clicked (background color changes) but other than that nothing seems to respond. if you look REALLY closely, you can see that actually the UI is responding and changing, but it's masked out behind the overlay screen.

Two suggestion, in my personal order of preference:

1. Clicking anywhere outside of the overlay just closes the overlay.
2. The overlay covers everything and you're essentially forced into clicking the 'Hide' button to reveal the UI behind it.

There's a short video of the behavior posted here:
https://twitter.com/statusquont/status/1278465322278948864

Below is a design for a comment @promag made here bitcoin/bitcoin#16432 (comment) about having a toggle option for the privacy mode proposed in the same PR.

Rather than the current user flow of checking/unchecking Menu->Settings->Mask Values users can quickly click the icon to toggle privacy mode on and off resulting in a cleaner flow / less cluttered menu options.

Tooltip - this should not pop up instantly as it does here but rather after a ~750ms delay (same as WindowsOS, which styling this design follows). Figma does not allow an instant delayed animation - it really should.

Why would a user want to have this feature toggled faster?

A hypothetical scenario would be if the user had the GUI open and someone walked behind them they could quickly conceal their private information by clicking this rather than the current flow which would take a second or two compared to milliseconds clicking the toggle.

Why V1? Whats next?

This version stays within the scope of bitcoin/bitcoin#16432 by only concealing information in the overview section of the GUI. Having privacy mode extended to the other menu options (e.g. concealing addresses / transaction hashes in transactions menu) is something that could be explored in a further version of this. The toggle would need to be moved to a global section for this, either in the bottom or top menu.

Figma source file
Icons used (these two icons are not currently in the GUI)

On the Overview panel there are 2 warning symbols: ⚠️ which would seem to indicate something of great importance to a user. But they don't currently provide any visual clue that they are actionable elements. If they had a more clickable-appearance (borders or beveled button edges) it could help users more quickly understand what they are being alerted to.

When starting Bitcoin Core 0.20.0-x86_64 ( https://bitcoin.org/bin/bitcoin-core-0.20.0/bitcoin-0.20.0-x86_64-linux-gnu.tar.gz) ) on Ubuntu 18.04 there is no option to set a custom data directory in the GUI.

All options in the GUI are greyed out. See image, please.

https://imgur.com/AmRCLyZ
After updating from 18. the GUI of bitcoin-qt opens up like this:

The same with version 19.
Version 18. still opens fine by the way
This is on Ubuntu 19.10, Gnome 3.34.2

-resetguisettings doesn't help

The Receive panel indicates that "all fields are optional" and if that is indeed the case, there is no clear visual cues what the correct action is -- it's to click the 'Create New Receiving Address' button.

Suggestion: give primary action buttons an orange background.

Here's an example from GitHub settings where a UI has multiple actions, but they visually guide the user to the action they should be taking with a colored button.

I got this idea from Android Studio/IntelliJ where they have a menu option to "Create Desktop entry..." and it generates a .desktop file for Gnome for example.

I created an entry for myself, but I didn't know where to get the icons at first. And I still don't know where the green icon for Testnet comes from. It would be convenient to have this option on bitcoin-qt as well.

Moved from bitcoin/bitcoin#11826.

This is a RFC regarding adding a new Activity window in the UI, which allows to:

• have activity history (truncated, etc);
• pause or cancel tasks if supported individually;
• have multiple progresses concurrently.

In terms of patch, ShowProgress() signal is removed everywhere and a RAII class is added along with some UI classes:

class Activity
{
    std::shared_ptr<ActivityData> const d;
public:
    Activity(const std::string& title);
    ~Activity();

    void SetTitle(const std::string& title);
    void SetProgress(int progress);
};

Consider this the minimal interface for an activity. Some other ideas:

• custom progress range (so the caller doesn't have to calculate percentage)
• add something like SetPause(bool), IsPaused();
• also Cancel() and IsCancelled();
• add something like SetSource(string) (for instance SetSource("wallet1")).

The current implementation is thread safe. For now, I've also added a new menu item Window where I think we could add Console too (another discussion thou).

Please see the capture below.

The Travis ASan instance will timeout. This was "fixed" by bitcoin/bitcoin#19321, so just rebase.

Ported from bitcoin/bitcoin#18602.

bitcoin-qt will fail if it does not have access to a functioning X display, even though when run with --help it doesn't need one.

For a while there's been a stack of Qt related warnings when building against Qt 5.15. Someone might want to take a stab at cleaning them up, assuming we can keep the code backwards compatible, without using too many hacks. There may be more than this, but these are all of the unique ones I could see:

  CXX      qt/libbitcoinqt_a-modaloverlay.o
qt/bitcoin.cpp:259:53: warning: 'QFlags' is deprecated: Use default constructor instead [-Wdeprecated-declarations]
    SplashScreen *splash = new SplashScreen(m_node, nullptr, networkStyle);
                                                    ^
/usr/local/Cellar/qt/5.15.0/lib/QtCore.framework/Headers/qflags.h:123:5: note: 'QFlags' has been explicitly marked deprecated here
    QT_DEPRECATED_X("Use default constructor instead") Q_DECL_CONSTEXPR inline QFlags(Zero) noexcept : i(0) {}

  CXX      qt/libbitcoinqt_a-peertablemodel.o
qt/bitcoingui.cpp:1308:29: warning: 'pixmap' is deprecated: Use the other overload which returns QPixmap by-value [-Wdeprecated-declarations]
        if (labelProxyIcon->pixmap() == nullptr) {
                            ^
/usr/local/Cellar/qt/5.15.0/lib/QtWidgets.framework/Headers/qlabel.h:77:5: note: 'pixmap' has been explicitly marked deprecated here
    QT_DEPRECATED_VERSION_X(5, 15, "Use the other overload which returns QPixmap by-value")

  CXX      qt/libbitcoinqt_a-coincontroltreewidget.o
qt/optionsmodel.cpp:222:59: warning: 'split' is deprecated: Use Qt::SplitBehavior variant instead [-Wdeprecated-declarations]
    QStringList ip_port = settings.value(name).toString().split(":", QString::SkipEmptyParts);
                                                          ^
/usr/local/Cellar/qt/5.15.0/lib/QtCore.framework/Headers/qstring.h:603:23: note: 'split' has been explicitly marked deprecated here
    Q_REQUIRED_RESULT QT_DEPRECATED_VERSION_X_5_15("Use Qt::SplitBehavior variant instead")

qt/transactionview.cpp:278:17: warning: 'QDateTime' is deprecated: Use QDate::startOfDay() [-Wdeprecated-declarations]
                QDateTime(current),
                ^
/usr/local/Cellar/qt/5.15.0/lib/QtCore.framework/Headers/qdatetime.h:296:5: note: 'QDateTime' has been explicitly marked deprecated here
    QT_DEPRECATED_X("Use QDate::startOfDay()") explicit QDateTime(const QDate &);

  CXX      qt/libbitcoinqt_a-moc_bitcoinaddressvalidator.o
qt/sendcoinsdialog.cpp:174:72: warning: 'buttonClicked' is deprecated: Use QButtonGroup::idClicked(int) instead [-Wdeprecated-declarations]
        connect(ui->groupFee, static_cast<void (QButtonGroup::*)(int)>(&QButtonGroup::buttonClicked), this, &SendCoinsDialog::updateFeeSectionControls);
                                                                       ^
/usr/local/Cellar/qt/5.15.0/lib/QtWidgets.framework/Headers/qbuttongroup.h:89:5: note: 'buttonClicked' has been explicitly marked deprecated here
    QT_DEPRECATED_VERSION_X_5_15("Use QButtonGroup::idClicked(int) instead")

Overview of current and new create wallet user flow

1.0 Who is this being designed for?

I am under the assumption that currently the Bitcoin core GUI primarily caters to Bitcoin power users and or developers who are okay with usability trade offs for improved security and more robustly audited code. With the GUI being one of the most secure, simple ways to run a full node, and if a goal of the Bitcoin community is to have as many full nodes as possible (which I presume it is), then we need the GUI to cater to a wider, less technical audience.

The aim of my designs is to remove friction for beginner and power users without having any security and or privacy trade offs, as well as have as minimal technical hurdles. Primarily, however, my goal is to make the GUI more beginner friendly. The Bitcoin core GUI in my view should be a benchmark / reference implementation and should not aim to be a flashy node software like umbrel or mynode – but this does not mean usability improvements cant be made. A well designed GUI will also further improve the security and privacy of its users - for this reason core should put more emphasis on design implementations. With good design, both the beginners and power users will be able to send and receive bitcoin backed by their own full node using the GUI without trade offs.

2.0 Problems being solved

The current user flow for creating a new wallet does not explain to users the types of wallets you can create or how each wallet type is different. Furthermore, the types of wallets available to create use terminology that is likely unfamiliar to many users (e.g. ‘Disable private keys’ could just be named ‘Watch Only Wallet’ which is more common and describes the same kind of wallet) - Luke Jr brang up this concern in bitcoin/bitcoin#17879.

The encrypt wallet option should be part of the create new wallet user flow and not optional (but also not mandatory – see below). The current initial modal that is presented does nothing to educate the user of the importance and pitfalls (not recoverable) of encrypting your wallet. This information could be included in the first modal but to keep things minimal and clean this should focus on ‘Choose your wallet type’ options whilst ‘Encrypt your wallet’ should have its on modal to fully explain why/why not to encrypt. Having encrypt wallet as part of the user flow by default will likely lead to better security of users bitcoin – An example being users will be more likely encrypt their wallets if informed why they should, this will lead to less stolen (but possibly more lost) bitcoins. If we want beginners using the GUI (meaning many more nodes) simple content changes such as this are important. Some discussions around this occurred in bitcoin/bitcoin#17879.

A general clean up of the UI without any drastic changes was also made. The design scope is quite limited due to Qt Widgets inheriting most components from the host OS. A cleaner UI generally leads to a smoother user experience. Nothing too fancy was done here, mostly some hierarchical separation of text, cleaner inputs and more consistent padding.

From a wider GUI perspective I chose to focus on the create new wallet feature first as creating a wallet and creating it securely is one of the most important things a bitcoin user can do so I figured this was a top priority.

3.0 Solutions

Below are the designs I have made with comments, along with the current screens for comparison. You can also view the figma file (opens in your desktop fine) if you want to view the source files and more specific details of the design. You can leave comments on my figma file by clicking the speech bubble in the top left and clicking the area of the design you want to comment on. Designs are done using the WindowsOS Qt widgets inherited styling. Linux and Mac versions will inherit their own styling but the primary elements will be consistent.

3.1 Create Wallet Meta

This is the first modal that pops up when creating a wallet, it is quite vague what it is the user needs to do here #69. Here are some questions that users likely have but are unanswered of which I aimed to answer or avoid the user having in the above new design – Why do I encrypt my wallet? It is selected by default so it must be important, but why is it important? What does disable private keys mean and why would I want that? Why is it disabled by default? What is a blank wallet and why would I want that? What are these options anyways? When I click create what exactly am I creating?

For a cleaner more practical flow, the first modal should focus on the meta of wallet creation such as the name / wallet type and move secondary steps like encrypting to a subsequent modal. Several wallet types can be created which is not clearly communicated, nor is what each of those wallet types can do. I included a standard wallet option which should be selected by default as this is likely the most common wallet type users will create. The encrypt wallet option has been moved to its own modal and should be a default option for creating any type of wallet (details in design below).

Minor Changes

The wallet name input should be pre-filled in with text such as ‘MyWallet1’ for users who want to quickly make a wallet. If the user already has say one wallet then the pre-filled text should be ‘MyWallet2,’ they have two wallets ‘MyWallet3,’ etc. This creates a quicker user flow and better user experience. Electrum wallet does this nicely when creating a new wallet.

Removed the help button ‘?’ at the top – currently does nothing and the new design should clarify any confusion the user may have- #74.

3.2 Create Wallet Encryption

Currently the encrypt wallet option is a toggled feature in the first modal, but as explained above this modal should focus on wallet meta options like wallet type/name. The encrypt wallet modal should be presented to all users after picking a wallet type regardless of the wallet type chosen and should clearly emphasize the pros and cons of encrypting. It should also still be optional to not encrypt your wallet which can be done by leaving the passphrase input blank – though the warnings should push users more towards encrypting for better security / privacy. A modal should pop up (last frame shown above) confirming the user does not want to encrypt if they leave the passphrase input blank. bitcoin/bitcoin#17879.

Much of this emphasis on the pros and cons of encrypting is placed AFTER the user encrypts their wallet in subsequent modals which does not make sense – the emphasis should be placed before they decide to encrypt or not. I did this by including the details from the modals that usually pop up after entering a passphrase at the header of this modal. I also added a warning in red to clearly indicate that cons of encrypting. Lastly, I added a checkbox input that must be clicked before the ‘create’ button can be clicked which finishes the wallet creation process.

Minor Changes:

Moved the passphrase visibility toggle to icons on each passphrase input. This is a cleaner, more user friendly approach. Also made each input have their own toggle rather than a toggle that just shows both inputs when clicked like in the current design. These are two new icons not currently in the GUI that will need to be added to implement this design.

3.3 Create Wallet extra redundant modals

With a more detailed encrypt wallet modal the two subsequent modals (shown above) can be removed making the create wallet process more seamless and involve less steps.

Next Steps

This was mostly a re-modelling of what currently exists - no extra frames / steps have been added. However, going forward I would also like to setup a user flow in this create wallet section of the GUI for watch only wallets and blank wallets. Such as having the ability to enter a xpub for watch only wallets in the creation process rather than in the settings after the wallet is created like it currently is.

Looking forward to some feedback!

Right now users have to use the RPC console to do imports. This is not a good experience. We should have a dialog that lets people import things into a wallet. This should probably mirror importmulti and importdescriptors; we can probably reuse some of that code.

• I understand priority is to keep things simple and secure however some users prefer dark theme.

• Dynamically change the theme to either light or dark.

• Almost every bitcoin wallet for desktop has dark theme.

• Those pictures are looking good: bitcoin/bitcoin#9639

• Did some research related to light/dark theme and qt although I am not the best person to suggest code related to design: https://github.com/Alexhuszagh/BreezeStyleSheets

Ported from: bitcoin/bitcoin#10296. This has had little follow up / discussion, and may not even be an issue any more (tested version was 0.14.0).

Describe the issue

First Issue
In Bitcoin Core 0.14.0 the Network Traffic graph in the Debug window displays erroneous traffic spikes when synchronizing the block chain. My internet connection is limited to 50 megabit/sec downstream yet the bursts are over 10 megabytes/sec, approximately twice the bandwidth that my internet connection should be capable of. Although theoretically my internal network could be buffering this traffic and sending it as a burst, these theoretical traffic bursts are not seen by the operating system's Task Manager or Resource Monitor applications therefor I believe it is safe to rule this out as the cause.

Second Issue
When you press the Clear button in the Network Traffic graph, and no network activity is taking place, it will not render a graphic for the graph. After a period of time when network traffic does take place it will render a flat line followed by a graph of the traffic

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

First Issue
Replicate the environment, begin to download the block chain and watch the traffic graph window for hours. I'm sure you could save yourself a lot of time by doing this programmatically and have your code look for traffic spikes which would exceed the available internet bandwidth.

Second Issue
Replication the environment, begin to download the block chain, wait for a period of no network traffic, press the clear button, wait for network traffic to resume.

Expected behaviour

First Issue
The network graph should display accurate traffic statistics.

Second Issue
The network graph should display a flat line during periods of no traffic

Actual behaviour

First Issue
There are erroneous traffic spikes.

Second Issue
A flat line is not displayed until traffic occurs after the graph has been cleared.

Screenshots.

First Issue
Please be aware that there is also iSCSI and Remote Desktop Services traffic accounted for in the Task Manager/Resource Monitor graphs. Even with this extra traffic, Task Manager/Resource Monitor does not display the same 10+ megabyte/sec traffic spikes.
Video of it happening with Task Manager - https://my.mixtape.moe/ugszqy.mp4
Screenshot of it happening with Resource Monitor:

Second Issue
Video of it happening - https://my.mixtape.moe/gcazhi.mp4

What version of bitcoin-core are you using?

0.14.0

Machine specs:

• OS: Windows Server 2016 Remote Desktop Services Session Host virtual machine with Bitcoin Core configured as a RemoteApp on a VMware ESXi 6.5 host
• CPU: 4 cores from a dual Xeon E5-2660v2 with high latency sensitivity and 100% resource reservations
• RAM: 4GB with 100% resource reservations
• Disk size: OS/Bitcoin Core 32GB, data directory 1TB
• Disk Type (HD/SDD): OS/Bitcoin Core is stored on the host as a VMDK on a 8x SSD RAID 0 VMFS6 datastore, the data directory is a thin provisioned LUN on a Microsoft iSCSI target server 2016 failover cluster running deduplication stored on the host as a VMDK on a 8x HDD RAID 6 VMFS5 datastore.
• Network: Cable Modem->Cisco ASA 5510 firewall->Two Cisco Aironet 1141 802.11n (2.4Ghz) APs configured as a workgroup bridge->Cisco Catalyst 3750E switch->ESXi host with a Intel X520 NIC as the uplinks for the VDS port group->VM with a VMXNET3 network adapter

Ported from bitcoin/bitcoin#13217.

Steps to reproduce:

1. Open QT console.
2. Run gettxoutsetinfo.
3. Exit the debug window (no blocking) -> exit the program (will block).

This is what is shown on Windows (10) for several minutes:
https://i.imgur.com/AyexgkC.png

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

The only ways to start QT with a different network is to launch it from the command line or edit bitcoin.conf. It would be nice if it can be done from the settings screen (a restart is fine).

With initiatives such as Bitcoin Design and square crypto grants being offered for Bitcoin designers, I think its important to have a UI/UX label for the likely new wave of designers entering the space in the coming years.

Design does not mean a 'fancy GUI', but a more usable and intuitive GUI. Good design means good usability, good usability is security.

Similar to bitcoin/bitcoin#19321

Useful skills:

Git, Bash

Want to work on this issue?

For guidance on contributing, please read CONTRIBUTING.md before opening your pull request.

Moved from: bitcoin/bitcoin#17969

What Happens

When you click File|Sign Message, the UI asks you to choose an address with which to sign. You can enter one by hand, paste from clipboard, or "Choose a previously used address." The third option provides a list of addresses that includes addresses for which there is no private key (P2SH addresses). This is intimately related to #10542 but the fix here is straightforward.

Expected Behavior

I expect addresses for which no private key is known to be excluded from the list presented. I realize that the same list is used to select an address to which to receive a payment, but that code could be adjusted to accept a filter, or the private-key-less addresses could be filtered out during display.

To reproduce

Ensure that you have at least one P2SH address in your Bitcoin core wallet.
Select File | Sign Message
Click the address book.
Note that there are P2SH addresses offered for selection.

This is in Bitcoin Core 0.18.

The Decrypt case is unused and should be removed. See

src/qt/askpassphrasedialog.h:        Decrypt     /**< Ask passphrase and decrypt wallet */

Want to work on this issue?

For guidance on contributing, please read CONTRIBUTING.md before opening your pull request.

The help button '?' on the create wallet modal (and the following encrypt wallet modal) does not do anything on WindowsOS. This does not exist on the Linux version, have not tested Mac.

Try to unlock wallet in the console with command line walletpassphrase fails if a comma is contained in the passphrase. The json parser wont allow it.

Expected behaviour

Should accept comma as valid character part of the passphrase.

Actual behaviour

eg: Try command in console window
walletpassphrase "km3k5h3lk,X$VG#$" 120

All the time.
eg: Try command in console window
walletpassphrase "km3k5h3lk,X$VG#$" 120

core 0.20.0

Tails OS

Tails OS

On master (dbd7a91):

$ lldb ./src/qt/bitcoin-qt -- -testnet
(lldb) target create "./src/qt/bitcoin-qt"
Current executable set to './src/qt/bitcoin-qt' (x86_64).
(lldb) settings set -- target.run-args  "-testnet"
(lldb) run
Process 5006 launched: './src/qt/bitcoin-qt' (x86_64)
Process 5006 stopped
* thread #1, name = 'bitcoin-qt', stop reason = signal SIGSEGV: invalid address (fault address: 0x38)
    frame #0: 0x00007ffff72e1fa0 libpthread.so.0`__GI___pthread_mutex_lock
libpthread.so.0`__GI___pthread_mutex_lock:
->  0x7ffff72e1fa0 <+0>:  movl   0x10(%rdi), %eax
    0x7ffff72e1fa3 <+3>:  movl   %eax, %edx
    0x7ffff72e1fa5 <+5>:  andl   $0x17f, %edx              ; imm = 0x17F 
    0x7ffff72e1fab <+11>: nop    
(lldb) bt
error: bitcoin-qt :: Class 'ClientModel' has a base class 'QObject' which does not have a complete definition.
error: bitcoin-qt :: Try compiling the source file with -fstandalone-debug.
* thread #1, name = 'bitcoin-qt', stop reason = signal SIGSEGV: invalid address (fault address: 0x38)
  * frame #0: 0x00007ffff72e1fa0 libpthread.so.0`__GI___pthread_mutex_lock
    frame #1: 0x00005555555ea443 bitcoin-qt`ClientModel::getBestBlockHash() [inlined] __gthread_mutex_lock(__mutex=0x0000000000000028) at gthr-default.h:748
    frame #2: 0x00005555555ea43b bitcoin-qt`ClientModel::getBestBlockHash() [inlined] std::mutex::lock(this=0x0000000000000028) at std_mutex.h:103
    frame #3: 0x00005555555ea42d bitcoin-qt`ClientModel::getBestBlockHash() [inlined] std::unique_lock<std::mutex>::lock(this=<unavailable>) at std_mutex.h:267
    frame #4: 0x00005555555ea42d bitcoin-qt`ClientModel::getBestBlockHash() [inlined] UniqueLock<AnnotatedMixin<std::mutex>, std::unique_lock<std::mutex> >::Enter(this=<unavailable>, pszFile=<unavailable>, nLine=119) at sync.h:139
    frame #5: 0x00005555555ea42d bitcoin-qt`ClientModel::getBestBlockHash() [inlined] UniqueLock<AnnotatedMixin<std::mutex>, std::unique_lock<std::mutex> >::UniqueLock(this=<unavailable>, mutexIn=0x0000000000000028, pszFile=<unavailable>, nLine=119, fTry=false) at sync.h:160
    frame #6: 0x00005555555ea42d bitcoin-qt`ClientModel::getBestBlockHash() [inlined] ClientModel::getBestBlockHash(this=<unavailable>)::$_2::operator()() const at clientmodel.cpp:119
    frame #7: 0x00005555555ea42d bitcoin-qt`ClientModel::getBestBlockHash(this=0x0000000000000000) at clientmodel.cpp:119
    frame #8: 0x00005555556a23f6 bitcoin-qt`TransactionTableModel::index(this=0x0000555556472cf0, row=11, column=4, parent=<unavailable>) const at transactiontablemodel.cpp:667
    frame #9: 0x00007ffff5a9c5e9 libQt5Core.so.5`___lldb_unnamed_symbol1919$$libQt5Core.so.5 + 249
    frame #10: 0x00007ffff5a9cb56 libQt5Core.so.5`QSortFilterProxyModel::flags(QModelIndex const&) const + 166
    frame #11: 0x00007ffff6adf3c5 libQt5Widgets.so.5`QListView::moveCursor(QAbstractItemView::CursorAction, QFlags<Qt::KeyboardModifier>) + 437
    frame #12: 0x00007ffff6aad083 libQt5Widgets.so.5`QAbstractItemView::focusInEvent(QFocusEvent*) + 259
    frame #13: 0x00007ffff68987ff libQt5Widgets.so.5`QWidget::event(QEvent*) + 2479
    frame #14: 0x00007ffff69394de libQt5Widgets.so.5`QFrame::event(QEvent*) + 30
    frame #15: 0x00007ffff6942623 libQt5Widgets.so.5`QAbstractScrollArea::event(QEvent*) + 899
    frame #16: 0x00007ffff6aac87b libQt5Widgets.so.5`QAbstractItemView::event(QEvent*) + 187
    frame #17: 0x00007ffff685983c libQt5Widgets.so.5`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 156
    frame #18: 0x00007ffff6861104 libQt5Widgets.so.5`QApplication::notify(QObject*, QEvent*) + 676
    frame #19: 0x00007ffff5adb8d8 libQt5Core.so.5`QCoreApplication::notifyInternal2(QObject*, QEvent*) + 280
    frame #20: 0x00007ffff685ecbe libQt5Widgets.so.5`QApplicationPrivate::setFocusWidget(QWidget*, Qt::FocusReason) + 526
    frame #21: 0x00007ffff68927ef libQt5Widgets.so.5`QWidget::setFocus(Qt::FocusReason) + 415
    frame #22: 0x00007ffff685f14b libQt5Widgets.so.5`QApplication::setActiveWindow(QWidget*) + 1067
    frame #23: 0x00007ffff685f243 libQt5Widgets.so.5`QApplicationPrivate::notifyActiveWindowChange(QWindow*) + 51
    frame #24: 0x00007ffff609eee5 libQt5Gui.so.5`QGuiApplicationPrivate::processActivatedEvent(QWindowSystemInterfacePrivate::ActivatedWindowEvent*) + 789
    frame #25: 0x00007ffff609f14d libQt5Gui.so.5`QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) + 557
    frame #26: 0x00007ffff60762eb libQt5Gui.so.5`QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 171
    frame #27: 0x00007fffecd98260 libQt5XcbQpa.so.5`___lldb_unnamed_symbol984$$libQt5XcbQpa.so.5 + 16
    frame #28: 0x00007ffff19d5417 libglib-2.0.so.0`g_main_context_dispatch + 743
    frame #29: 0x00007ffff19d5650 libglib-2.0.so.0`___lldb_unnamed_symbol192$$libglib-2.0.so.0 + 512
    frame #30: 0x00007ffff19d56dc libglib-2.0.so.0`g_main_context_iteration + 44
    frame #31: 0x00007ffff5b3488f libQt5Core.so.5`QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 95
    frame #32: 0x00007ffff5ad990a libQt5Core.so.5`QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 314
    frame #33: 0x00007ffff5ae29b4 libQt5Core.so.5`QCoreApplication::exec() + 148
    frame #34: 0x00005555555d2985 bitcoin-qt`GuiMain(argc=<unavailable>, argv=<unavailable>) at bitcoin.cpp:594
    frame #35: 0x00005555555cea43 bitcoin-qt`main(argc=<unavailable>, argv=<unavailable>) at main.cpp:21
    frame #36: 0x00007ffff3c7db97 libc.so.6`__libc_start_main(main=(bitcoin-qt`main at main.cpp:21), argc=2, argv=0x00007fffffffdcf8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffdce8) at libc-start.c:310
    frame #37: 0x00005555555ce96a bitcoin-qt`_start + 42

Moved from bitcoin/bitcoin#11564.

Currently the send screen displays the fee in terms of (μ/m)BTC/kB, depending on a global preference. When entering a custom fee the user can select (μ/m)BTC using a dropdown. The resulting numbers are quite hard to read, often with five leading zeros.

This makes it too easy to make an off-by-ten mistake, especially because the wallet doesn't display fiat values.

I think Sat per Virtual Byte (vByte?) makes for more readable numbers. People generally find numbers between 0.01 and 100 easy to work with, because they're used to cents and dollars. Several fee estimators currently use Sat/vByte, where 1 is the minimum relay fee, 10-100 is the usual range, people start complaining when it goes over.

I also think this choice is quite durable, even if the price increases by orders of magnitude and fees get worse (low fees would not really be a UX issue). Assuming fees in dollar terms stay in the same range, or even a factor ten more, Sat/vByte produces easy to read numbers for a price range of $500 (100 - 1000 sat/vByte) to $5 million (0.01 - 0.10 sat/vByte).

In this case the (μ/m)BTC dropdown could be removed from the fee UI; I don't think the users currency preference (μBTC / mBTC / BTC) should be applied to the fee UI. This preference makes sense for the users balance, for a transaction amount and the absolute fee value.

There would still some confusion if people look at other fee estimators on the web which currently often user fee per byte, based on non-segwit transactions.

Hopefully the industry will trend towards a single metric for fees, so people can develop an intuition for them, decreasing the likeliness of mistakes.

I can make a PR is people think this is a good idea.

Ported from bitcoin/bitcoin#17734.

Bitcoin Core makes itself the default handler for BIP21 style bitcoin:... URIs. Other wallets also do this, so the default wallet often depends on whatever the user installed most recently.

In macOS the only way to change this setting is to edit a plist file (to org.bitcoin.BitcoinPayment, requires reboot) or run some freeware program to do it. I don't know the situation on other operating systems.

We should add a button to the settings screen to make Bitcoin Core the default URI handler.

Any report, issue or feature request related to the GUI should be reported at
https://github.com/bitcoin-core/gui/issues/

Overview of current on boarding process (old top, new bottom).

1.0 Problems

In general, the on-boarding is very limited / almost non-existent. Having an on-boarding process is one of the best ways to educate users about features (wallet / node) and other more general info (privacy / security practices). Currently the user is thrown into the deep end with the GUI without a clear explanation as to what is going on or what steps to take next.

No option to select the users language exists in the current on-boarding. Having this as the first option will significantly improve the UX for non-English users (the current default language). Currently, the only way to set language is within the GUI itself which means non-English users will likely miss the current node info welcome screen.

Details such as what is the Bitcoin core GUI, what is a node, why should you run a node, and what is a pruned node are not clearly articulated / given the importance they deserve in the current welcome screen. This is mostly due to a cluttered UI and unclear explanations. #26

2.0 Solutions

This on-boarding process is only gone through when the user launches the GUI for the first time after installation. Each design has had a cleaning up of its UI. Design specifics (padding, margins, fonts etc.) can be found in my figma design source files - feel free to leave comments on figma directly by clicking the speech bubble in the top left and clicking the part of the design you wish to comment on.

2.1 New Welcome Screen

This new welcome screen gives a simple explanation to the user what the GUI is. Although this might seem trivial I've seen some users who have downloaded the GUI still unclear on this point. The download page on bitcoincore.org/en/download does not explain the features of the GUI so I understand the confusion some may have.

2.2 Your Full Node Screen

3.0 Extra

Why am I doing this in versions?
Breaking up designs into more manageable steps, much like using atomic commits, make things easier from an implementation perspective. V1 is primarily a content re-work and does not involve any major technical changes.

V2 (WIP) will have basic wallet creation embedded. Currently the GUI automatically creates a default wallet on launching without prompting the user it was created or giving them any details about wallets which can lead to a lot of confusion bitcoin/bitcoin#15454. The create wallet flow for the on-boarding will be similar to what I have done here #77

V3 I'd like to explore having HWI and other more complex ways to load and create wallets.

Design constraints
The Bitcoin Core GUI uses Qt Widgets which inherits most of its design components from the host OS, this design was done for WindowsOS but should translate nicely to MacOS and Linux. If people would prefer me to do these designs in Linux or MacOS instead please let me know.

Figma source file

Moved from: bitcoin/bitcoin#7734.

The current QT GUI shows some network status indicators in the bottom right.

I'd like someone to add one for Tor. It might be the Tor onion logo that is either green, yellow (if going through some not-quite-ready stage) or with a circle and line striking through it when not connected via Tor.

This would complement the Tor-related improvements in 0.12.0 and make it easier for users to determine whether they are connected via Tor without doing additional investigatory steps, such as using the -debug=tor switch.

Moved from bitcoin/bitcoin#16954.

Continued discussion from bitcoin/bitcoin#16944 (comment), based on @gwillen's offline signing branch: https://github.com/gwillen/bitcoin/tree/feature-offline-v2

If we make the entire Send experience a modal, things might get a bit simpler.

Sorry for the handwriting :-) There's 3 stages to a transaction:

1. Draft / compose: enter recipient, amount, fees, etc. (the current Send screen).

This step is skipped when loading a PSBT (e.g. via menu: Transaction -> Load, or a smart clipboard).

2. Sign: currently a popup which confirms the details. With hardware wallets (e.g. #16549) this should enumerate connected wallets and let you sign one by one. In a multisig situation it should detect if any signatures are missing, and rename the 3rd step to "Export".

3. Finish / Export: once again repeat the importantant details. For basic wallets with private keys in it, this should just show that the transaction has been broadcast. With a completed PSBT it should let the user choose between broadcasting or exporting (clipboard, save to disk).

Moved from bitcoin/bitcoin#9464. Low prio, could probably just be closed as wont-fix.

OSX 10.12.2, Qt 5.7.1, master at 2a524b8.

Running with bitcoin-qt -reindex-chainstate, "Number of blocks left" in the modal overlay never updates, and remains as "Unknown. Syncing Headers (446424)...". Even though we've synced > 200'000 blocks.