Bitcoin-Qt (Settings) reports incorrect "Size of database cache"

[unsystemizer]

$ ./bitcoin-0.15.1/bin/bitcoind --version
Bitcoin Core Daemon version v0.15.1
Copyright (C) 2009-2017 The Bitcoin Core developers
$ cat .bitcoin/bitcoin.conf | grep dbcache
dbcache=8000

debug.log reflects the correct amount:

2017-11-29 17:26:04 * Using 7990.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)

However, the UI does not:

Both Bitcoin-Qt and bitcoind log the correct amount, only Bitcoin-Qt UI reports 450 MB instead of 8 GB.
I tried to start it with -dbcache=8000, it still shows 450 MB.

• Ubuntu 17.10 x64
• Bitcoin 0.15.1 downloaded from bitcoincore.org

[Varunram]

I don't think qt spin-boxes can be set to a specific value (at least acc to the documentation here: http://doc.qt.io/qt-5/qspinbox.html). Since at startup, we default to 450, we could change the minimum value of the spin-box to the cli value. This however, would prevent the user from reducing the db cache size from the cli value. What do you suggest?

[unsystemizer]

I suppose this question is meant for the devs, but just in case: I suggest to just show (display) it. Because right below there's Open Configuration File and the instructions (how to override) are above that button which makes it easy to both see the current setting and know how to change it without reading documentation. The only thing that's missing (see other parts of the GUI) would be advice that a restart is required for the new setting to to take effect. (In case dbcache isn't set in bitcoin.conf, I assume the default value would be displayed).

[jonasschnelli]

The problem:

• If you set a DBCache in the GUI, you overwrite the bitcoin.conf value.

The layers are

• Defaults
• Bitcoin.conf
• startup cli arguments
• GUI

We should at least inform the user that the GUI set value does overwrite in case it's set.

[unsystemizer]

@jonasschnelli if you set DBCache in the GUI, bitcoin.conf remains unchanged.
The same goes for par in the same window.

[Varunram]

@unsystemizer I think what he means is that it supersedes the bitcoin.conf value in that run, not overwrites.

[jonasschnelli]

@unsystemizer: Yes. The bitcoin.conf files gets never changed by Core. But GUI / QT settings are stored in a different file and supersedes the settings in bitcoin.conf.

[valentinewallace]

Hey guys, played around and I think I might have a fix(?). In optionsmodel.cpp, I check if the -dbcache flag and if it's set, I set the settings value to be the value of the flag and it displays the correct value in the options menu.

Is there some reason this is not good? I'm new. otherwise, i'll submit a PR! :)

Edit: given no flag, it now starts with the dbcache value in bitcoin.conf. This seems to make sense to me..

[unsystemizer]

Sounds good, but if the value is set to something higher or lower and saved elsewhere, will the correct value be displayed?

One part I don’t understand is what if bitcoind is started instead of Bitcoin-Qt, does the custom value from Qt not take effect in that case? That would be very confusing (if cache changed depending on how you start). But that is a separate thing from the issue at hand, so at least if the correct value was displayed I would be happy as far as this issue is concerned.

[Varunram]

I think so, because qt doesn't overwrite the config in the conf file as pointed out earlier. This would be a usability issue, so I guess someone from Core would have to comment about this.

[jnewbery]

@Varunram - you're correct. The qt settings don't overwrite the bitcoin.conf settings, so if they're updated in qt, and then bitcoind is later started, the settings in bitcoin.conf will be used.

[jnewbery]

Note that if the bitcoin.conf settings are overriding the qt settings, then you should see the following in the options window:

[hebasto]

Tested after #14375 merging.

Case A

$ cat bitcoin.conf | grep dbcache
dbcache=3000
$ bitcoin-qt

Options window:

Case B

$ cat bitcoin.conf | grep dbcache
dbcache=3000
$ bitcoin-qt -dbcache=2000

Options window:

IMO, the GUI behaves as expected.

@MarcoFalke, @fanquake, @jonasschnelli Close?