Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wallet / qt: confirmed transaction labeled "open" #13299

Closed
adiabat opened this issue May 21, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@adiabat
Copy link

commented May 21, 2018

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:

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.

@fanquake fanquake added GUI Linux/Unix and removed Linux/Unix labels May 21, 2018

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented May 22, 2018

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.

@MarcoFalke MarcoFalke added the Bug label May 22, 2018

@adiabat adiabat closed this May 22, 2018

@adiabat adiabat reopened this May 22, 2018

@adiabat

This comment has been minimized.

Copy link
Author

commented May 22, 2018

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.

laanwj added a commit that referenced this issue Jan 15, 2019

Merge #14556: qt: fix confirmed transaction labeled "open" (#13299)
fb3ce75 Don't label transactions "Open" while catching up (Hennadii Stepanov)

Pull request description:

  Fix #13299.

  Since the default `nSequence` is `0xFFFFFFFE` and locktime is enabled, the checking `wtx.is_final` is meaningless until the syncing has completed (ref: #1026).

  This PR makes the wallet mark a transaction "Unconfirmed" instead of misleading "Open for NNN more blocks" when syncing after a period of being offline.

  Before this PR (with the issue):
  ![screenshot from 2018-12-12 15-56-23](https://user-images.githubusercontent.com/32963518/49874288-cdd06880-fe26-11e8-8441-f3ceb479611b.png)

  With this PR (the issue has been resolved):
  ![screenshot from 2018-12-12 15-54-41](https://user-images.githubusercontent.com/32963518/49874336-e9d40a00-fe26-11e8-8c05-9aeee2eb1bba.png)

Tree-SHA512: 358ec83b43c266a4d32a37a79dda80e80d40a2b77ad38261c84a095e613399f674aa7184805b3f6310e51ddb83ae2636b8849fcc7c4333e1b3ecbb0f70ad86d3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.