wallet / qt: confirmed transaction labeled “open” #13299

issue adiabat openend this issue on May 21, 2018
  1. adiabat commented at 11:17 pm on May 21, 2018: none

    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: https://github.com/bitcoin/bitcoin/blob/048ac8326b6952244f6e4453f4f8f6ab423eb926/src/qt/transactionrecord.cpp#L177 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.

  2. fanquake added the label GUI on May 21, 2018
  3. fanquake added the label Linux/Unix on May 21, 2018
  4. fanquake removed the label Linux/Unix on May 21, 2018
  5. MarcoFalke commented at 0:48 am on May 22, 2018: member

    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.

  6. MarcoFalke added the label Bug on May 22, 2018
  7. adiabat closed this on May 22, 2018

  8. adiabat reopened this on May 22, 2018

  9. adiabat commented at 2:44 am on May 22, 2018: none

    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.

  10. hebasto referenced this in commit d462446e1c on Oct 23, 2018
  11. hebasto referenced this in commit ff3ec22db7 on Nov 5, 2018
  12. hebasto referenced this in commit 7bd5c0dafa on Nov 5, 2018
  13. hebasto referenced this in commit ed54363a39 on Nov 5, 2018
  14. hebasto referenced this in commit 1b75945b06 on Nov 5, 2018
  15. hebasto referenced this in commit 6da8e1e52f on Nov 5, 2018
  16. hebasto referenced this in commit e8c7f70a41 on Dec 16, 2018
  17. hebasto referenced this in commit 0993d1cbb5 on Dec 16, 2018
  18. hebasto referenced this in commit 6d97da08c5 on Dec 17, 2018
  19. laanwj closed this on Jan 15, 2019

  20. laanwj referenced this in commit e8ad580f51 on Jan 15, 2019
  21. christiancfifi referenced this in commit 62f607c4ca on Oct 3, 2021
  22. christiancfifi referenced this in commit 5945e27855 on Oct 4, 2021
  23. christiancfifi referenced this in commit 2feead760f on Oct 6, 2021
  24. christiancfifi referenced this in commit 094b8736c0 on Oct 11, 2021
  25. christiancfifi referenced this in commit 5fb15a98aa on Oct 14, 2021
  26. pravblockc referenced this in commit 04c3e5f583 on Nov 18, 2021
  27. DrahtBot locked this on Dec 16, 2021
  28. gades referenced this in commit d539460238 on Jun 4, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-18 18:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me