Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
wallet / qt: confirmed transaction labeled "open" #13299
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:
which looks related; the ui may not be updating finality properly.
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.
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
I suggest to check if
I suggest to check if
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
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