gui
gui copied to clipboard
bitcoin-core
tx tooltip shows "i-1 confirmations" for quite a while after transaction details window is already showing "i confirmations"
tx tooltip shows "i-1 confirmations" for quite a while after transaction details window is already showing "i confirmations"
Expected behavior
tx tooltip up to date with transaction details window
Actual behavior
tx tooltip shows "i-1 confirmations" for quite a while after transaction details window is already showing "i confirmations". After receiving a new block. Several minutes!
To reproduce
Boot Bitcoin Core Qt, wait for a new block.
System information
Self-compiled v22.0 tag.
Contemporary Debian GNU/Linux, KDE 5.54.0, Qt 5.11.3, xcb. CPU is quite old, and disk interface is USB.
Other
Unconfirmed on testnet.
I have seen this twice on two different mainnet runs.
Then I run testnet and work OK.
Then I run mainnet again and happened again, after around ten minutes validating block 0000000000000000000c0d87f8e3e964f4b2238cff589a128b353108a2fb037b (height 701131).
It suppose it could be related to how an old computer and/or slow interfaces validate the blocks chain.
I wouldn't know how to set up a test case so that I could try to bisect this.
Apparently the synced/unsynced low bar icon tooltip is immediately in sync with the transaction details window, while the transaction tooltip stays "one block late".
Then I run mainnet again and happened again, after around ten minutes validating block 0000000000000000000c0d87f8e3e964f4b2238cff589a128b353108a2fb037b (height 701131).
Without closing Bitcoin Core Qt, next thing I knew, it is at block 0000000000000000000ca61f80e4b2e93961da04166f9911608262cd8b609335 (height 701135) with every label correctly in sync. But it has just been frozen for several seconds.
Thank you for reporting this. I am able to confirm that the tool-tip lags behind the actual confirmation count.
This is confined to initial startup. Upon startup it does infact start with i-1 in the case where blocks need to be processed because the client had not been online. If the client is caught up, then restarted, the tooltip for a transaction will not display i-1 confirmations.
jarolrod commented 18 hours ago: Thank you for reporting this.
Thanks to @diegoviola who discovered this independently a couple of days ago.
I wrote: But it has just been frozen for several seconds.
That must be just how "GUI event loop should be block free (17145)" appears on my low end and very old hosts.
It seems the relevant code: https://github.com/bitcoin-core/gui/blob/571bb94dfb5047c9be8fcbae5dae71de7256b86c/src/qt/transactiontablemodel.cpp#L586-L587
I think all it lacks could be just one new call to TransactionTableModel::updateConfirmations() at some precise location.