There is finally a decently working Bitcoin Core GUI (bitcoin-gui)

[broflof]

It seems that there is now a new GUI program of Bitcoin Core - bitcoin-gui. I noticed it when I was about to compile Bitcoin Core from source. It was not very well described anywhere but I found some information that it's a new multithreaded or multiprocessing client. That sounded interesting so I tried it.

And it really seems to make a huge difference in comparison to the old GUI client (bitcoin-qt). Finally there is a client which does not completely stall its user interface for minutes at a time when it's synchronizing. The GUI seems to work properly all the time no matter what it's doing.



My earlier experiences were very disappointing:

I started Bitcoin-qt 31.1 (from Fedora linux repositories). First it gave a pop up message, stating that a wallet can't be found and it's likely so because a legacy wallet must be migrated.

So I chose the "migrate wallet" option from menu. A pop up window with a progress bar appeared but it took forever to "migrate", not sure what it was even doing. Then I closed the migration window because I thought that it was stuck. But suddenly, after some time, it gave a message that migration was successful?? Was the migration function stalled when the client was synchronizing, just like the GUI stalls like that??

Hard to trust my wallet to a program that behaves like this.

Then after syncing for some time, there was an error message about disk space being too low. But about 60% of disk space was actually free (more than 1 TB free). I suspect that there was an error with the disk itself because my Monero blockchain corrupted at the same time. But why did Bitcoin-qt give such a misleading error message??

I thought that the blockchain was probably corrupted now so I started Bitcoin-qt with "bitcoin-qt -reindex". It went through the first stage fine, but during the next stage it stalled completely at some point, and there was again an error about disk space being too low, in the debug log??

At that point I thought that it's better to download the blockchain again from scratch (files are probably corrupted and -reindex takes forever anyway) and also decided to compile the client myself, not trusting what Fedora packagers had made.

[LoyceV]

I suspect that there was an error with the disk itself because my Monero blockchain corrupted at the same time.

So you're syncing Bitcoin Core on a disk with errors? That's just asking for problems.

[broflof]

I suspect that there was an error with the disk itself because my Monero blockchain corrupted at the same time.

So you're syncing Bitcoin Core on a disk with errors? That's just asking for problems.

Not sure about that. I couldn't find anything in dmesg (checked it only after the second case), and disk diagnostics data is clean, so I don't know yet if the disk is faulty. It could have been some kind of I/O error too.

If such problems occur again, I'll probably put blockchains to a different disk.

[takuma sato]

It seems that there is now a new GUI program of Bitcoin Core - bitcoin-gui. I noticed it when I was about to compile Bitcoin Core from source. It was not very well described anywhere but I found some information that it's a new multithreaded or multiprocessing client. That sounded interesting so I tried it.

And it really seems to make a huge difference in comparison to the old GUI client (bitcoin-qt). Finally there is a client which does not completely stall its user interface for minutes at a time when it's synchronizing. The GUI seems to work properly all the time no matter what it's doing.



My earlier experiences were very disappointing:

I started Bitcoin-qt 31.1 (from Fedora linux repositories). First it gave a pop up message, stating that a wallet can't be found and it's likely so because a legacy wallet must be migrated.

So I chose the "migrate wallet" option from menu. A pop up window with a progress bar appeared but it took forever to "migrate", not sure what it was even doing. Then I closed the migration window because I thought that it was stuck. But suddenly, after some time, it gave a message that migration was successful?? Was the migration function stalled when the client was synchronizing, just like the GUI stalls like that??

Hard to trust my wallet to a program that behaves like this.

Then after syncing for some time, there was an error message about disk space being too low. But about 60% of disk space was actually free (more than 1 TB free). I suspect that there was an error with the disk itself because my Monero blockchain corrupted at the same time. But why did Bitcoin-qt give such a misleading error message??

I thought that the blockchain was probably corrupted now so I started Bitcoin-qt with "bitcoin-qt -reindex". It went through the first stage fine, but during the next stage it stalled completely at some point, and there was again an error about disk space being too low, in the debug log??

At that point I thought that it's better to download the blockchain again from scratch (files are probably corrupted and -reindex takes forever anyway) and also decided to compile the client myself, not trusting what Fedora packagers had made.

Im not familiar with this "Bitcoin-gui" software. Could you post a direct link to it?

I have been using Bitcoin-qt since the beginning and I use the linux terminal window in order to see what is actually happening behind the curtain by looking at the debug.log file in real time, which is the best way I've found to know what the program is actually doing because as you said, the GUI often does dodgy stuff like slap a loading bar in there. I also remember the migration thing when testing that option, I thought it was frozen. Same goes for sometimes not seeing any progress on loading blocks and verifying them, but they are actually being downloaded and verified and there is progress being made if you look at the debug.log file.

The GUI needs a lot of work to make it more user friendly. Features like PSBT are still too convoluted. Making a watch-only wallet doesn't properly work because the transactions don't show up in correct order etc and you have to use the console command in order to do the importdescriptors thing. And I had to do some complex script with the .json file to get the labels to show up. I eventually just gave up on using it for now until it improves. I wish I could just use the original client for cold storage, transacting and running the node but it needs work.

[ABCbits]

Im not familiar with this "Bitcoin-gui" software. Could you post a direct link to it?

He probably refer to https://github.com/bitcoin-core/gui. But FYI, bitcoin-gui binary also shipped with pre-compiled Bitcoin Core these days. For example, bitcoin-31.1-x86_64-linux-gnu.tar.gz bundle it inside bitcoin-31.1/libexec/bitcoin-gui.

[broflof]

Im not familiar with this "Bitcoin-gui" software. Could you post a direct link to it?

He probably refer to https://github.com/bitcoin-core/gui. But FYI, bitcoin-gui binary also shipped with pre-compiled Bitcoin Core these days. For example, bitcoin-31.1-x86_64-linux-gnu.tar.gz bundle it inside bitcoin-31.1/libexec/bitcoin-gui.

If you download the source tree and compile everything you get two GUI apps - bitcoin-qt and bitcoin-gui and apparently the latter is multithreaded or something, and it also works much better, its interface doesn't stall like bitcoin-qt does. So I'm using it now. I suppose that both have the same functionality.

[promise444c5]

its interface doesn't stall like bitcoin-qt does. So I'm using it now. I suppose that both have the same functionality.

Why do you experience that though?? Or should i ask in what aspect..

[LoyceV]

Or should i ask in what aspect..

Bitcoin Core's GUI gets unresponsive while syncing blocks. It's okay when it's fully synced.

[achow101]

bitcoin-qt and bitcoin-gui are built from the same code, and are almost identical in behavior.

bitcoin-qt is a monolithic program where all of the node stuff is included in the binary and is executed as part of the same OS process as the gui.

bitcoin-gui contains just the gui, and it will spawn a separate process that executes bitcoin-node. All of the node stuff happens in the process for bitcoin-node. All of the gui stuff is in bitcoin-gui, and it communicates with bitcoin-node for the information it needs.

bitcoin-gui is part of the work towards the multiprocess project. This work is not complete and the binaries are still experimental. Use them at your own risk. The main benefit is that, in theory, if something were to kill the gui (e.g. an assertion error), the node won't be killed. This may not hold true in practice, depends on your OS and how it deals with child processes.

The multiprocess project does not change anything with how threading works. It does not change what things hold which locks - if something stalls the gui in bitcoin-qt, it'll also stall the gui in bitcoin-gui. In fact, it'll probably be worse because there is overhead in the interprocess communication required for multiprocess.

[Danish Ali]

The multiprocess project does not change anything with how threading works. It does not change what things hold which locks - if something stalls the gui in bitcoin-qt, it'll also stall the gui in bitcoin-gui.

That there is something of a contradiction here: multiprocess separation will not alter the way the program threads or locks, and may well result in more overhead caused by IPC, but users like @OP seem to indicate a reduction in GUI freezes, which may be an observation of the actual running of the code.

My guess is it is not that lock conflict is gone, but that because bitcoin-gui is a completely separate process it can still have time to redraw its window and react to basic OS events (like resizing/moving) when bitcoin node is busy and starving the interface. The actual freezes (waiting on node data) are therefore most likely still in place in this case. It may only feel more responsive, since the window isn't freezing like a single process application under load.

If it is what you have said, then it would be nice to know if it's that or something else.

[achow101]

My guess is it is not that lock conflict is gone, but that because bitcoin-gui is a completely separate process it can still have time to redraw its window and react to basic OS events (like resizing/moving) when bitcoin node is busy and starving the interface.

My guess is confirmation bias.

The single process program is multithreaded and all of the node stuff happens in a separate thread, which itself also spawns multiple threads.

[Dark.Look]

My guess is confirmation bias.

Perhaps but he wouldn't have been able to tell better or worse in the comparison. Compare the two runs to see what is differece. He packaged bitcoin-qt 31.1 with a selfcompiled of bitcoin-gui a disk he suspected of i/o errors with a new one and a chainstate he believed was corrupt with a brand new blockchain downloaded again frorm the beginning. There are three variables and one observation.
You have more experiance but I think if you really want to resolve it now @ABCbits already noted the easy way. The binaries are in the same tarball in bitcoin-31.1/libexec/bitcoin-gui. Same build and same datadir and the same block range. Do this for an hour and time the window's not repainting any more then swap and repeat.

[Danish Ali]

My guess is confirmation bias.

The single process program is multithreaded and all of the node stuff happens in a separate thread, which itself also spawns multiple threads.

Well, fair, it is a good test to my earlier assumption, if the node work is already in different thread(s) in bitcoin-qt, then technically my theory of "separate process = smoother repaint" doesn't really make much sense as it would only change the node work itself.

So if it is actually the same on both sides (bitcoin-qt as opposed to bitcoin-gui), excluding any hard-dollar difference between the two, would there be a difference in reported sensation/expectation of testing this "new" build?

You have more experiance but I think if you really want to resolve it now @ABCbits already noted the easy way. The binaries are in the same tarball in bitcoin-31.1/libexec/bitcoin-gui. Same build and same datadir and the same block range. Do this for an hour and time the window's not repainting any more then swap and repeat.

A good argument, and a much cleaner voicing of the matter than just guessing from that setup. Basically broflof's setup that started this had too much of the variables changing at once to get a testable case for it being a real difference or confirmation bias.

I think that the same tarball, same datadir, same block range, timed both ways is the right test. In any case, if someone actually does it, I would be interested in seeing the actual numbers.