wallet / qt: confirmed transaction labeled "open"

[adiabat]

When syncing after a period of being offline, a transaction that the wallet received during the offline period was seen in a block, and the transactions tab in the QT ui showed the transaction. However the transactions was not shown as "confirmed" but instead "open". Also, the number of confirmations seems to be incorrect.

I expected the clock icon that fills in as it downloads more blocks, followed by a check mark once it sees 6 confirmations.

Instead there was no icon, and a mouse-over showed "open for next 130 blocks". This confused me as the transaction wasn't a coinbase tx, didn't use op_csv or anything like that. The transaction did have a locktime, but the bitcoind wallet has been setting that for a while.

Eventually the icon switched directly to a check-mark, and a mouse-over showed the number of confirmations. However, the number of confirmations is too low by about 30 (a bit of a guess as I get tx details and then check the block height the UI reports it's synced to).

The receiving address was a bech32 native segwit v0 address, which may be related. I asked @theuni and he pointed out code around here:

bitcoin/src/qt/transactionrecord.cpp

Line 177 in 048ac83

if (wtx.lock_time < LOCKTIME_THRESHOLD)

which looks related; the ui may not be updating finality properly.

system:
0.16.0, linux, downloaded from bitcoincore.org, checked gpg sig.

Ubuntu 16.04, laptop hard drive.

This is not a huge issue but I think it could be confusing to users as it indicates that the transaction is not confirmed even though it really is. The UI eventually displays confirmed though.

[maflcko]

a transaction that the wallet received during the offline period was seen in a block, and the transactions tab in the QT ui showed the transaction. However the transactions was not shown as "confirmed" but instead "open"

I assume the transaction has a lock time specified as block height. Thus, when receiving the transaction through a block, its lock time must be that block's height or less. My understanding is that only a reorg that excludes this tx could display the transaction as "open", since other interfaces (rpc/p2p) reject such "open" transactions with non-final (code 64). (Also, unrelated to this issue report, the Bitcoin Core wallet wouldn't create "open" transactions, c.f. assert(txNew.nLockTime <= (unsigned int)chainActive.Height()); in wallet.cpp)

I suggest to check if getchaintips shows any valid forks just to rule out the possibility of a reorg. (Just noting that a 130 block reorg that went unnoticed seems very unlikely to me)

Eventually the icon switched directly to a check-mark, and a mouse-over showed the number of confirmations. However, the number of confirmations is too low by about 30 (a bit of a guess as I get tx details and then check the block height the UI reports it's synced to).

I suggest to check if gettransaction $txid shows the same number of confirmations as the gui and if the time is different from the blocktime and timereceived. Further gettransaction returns you a hex, which you can put into decoderawtransaction to compare the locktime against the other times.

[adiabat]

The bitcoin-qt node is now synced up to the current block height, and mouse-over displays the correct number of confirmations. Looking at debug.log I see only the normal AddToWallet $txid new message.

This tx was around height 522030, and I don't think there were any reorgs around then; the node displaying the UI bug was directly connected to another node on a server I control which was synced up, so I'm quite sure there were no reorgs or anything strange being sent to the QT node.

I think it's a QT UI only bug as I haven't seen anything weird in the CLI output or log files. Even during sync when I checked with gettransaction in the QT console it looked fine, and showed confirmations.