Strange state (Timestamps wrong) after importing a priv key.

kollokollo commented at 7:19 am on November 16, 2017: none

Describe the issue

After importing a private key from an old wallet, the rescan tool a long time, but after completion all Timestams belonging to transactions related to the newly imported key are wrong.

What behavior did you expect?

Show the correct timestamps of all trasactions, corresponding to the block the transaction took place.

see screenshots. The newly imported key has the label “ehemals”, The big number for confirmations (in the tooltip) seems to be correct, but the timestamps all show the time of the latest transaction (lieferando) which was there at the time of import.

How reliably can you reproduce the issue, what are the steps to do so?

Have not reproduced this issue yet (because it takes sooo long). But I have observed other strange things before (data curruption, see: Issue #11627).

What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)?

Bitcoin core from the ppa used on Ubuntu 17.4 (most recent, I think) Bitcoin core version: v0.15.0.0-g3751912e8e (64-Bit)

What type of machine are you observing the error on (OS/CPU and disk type)?

Ubuntu 17.04 64 bit, Quadcore CPU, 2GB RAM, HDD and SSD (for chainstate).

Any extra information that might be useful in the debugging process.

Everything else seems normal. The blockchain was freshly reindexed the 3 days before the import.(to cure the data corruption). The former issue “data corruption” was observed on a different computer, I then used a desktop computer. But I use the same (extermal) HDD.

kollokollo commented at 7:21 am on November 16, 2017: none

(Screenshots upload now works)

As mentioned above: the timestamps of all transactions “ehemals” were wrong. Timestamps of “liferando” is correct. Number of confirmations in the tool-tip seems t be correct as well.

The timestamp of the transaction to (n/a) seems to be correct, but obviosly the address is not there. This transactions does not correspond to the imported key, but was already there in the wallet before (and used to be displayed correctly).

kollokollo commented at 7:57 am on November 16, 2017: none

You may also want to know, that I have spent a part of the the bitcoins imported with the key already (transaction dated 2017-11-14) and that worked.

laanwj added the label Wallet on Nov 16, 2017

Popkultur commented at 3:00 pm on November 17, 2017: none

one might want to try to change your OS time from DST to non-DST or something to reproduce these errors.

maflcko commented at 7:07 pm on November 27, 2017: member

@kollokollo Are all those 6 transactions included in the same block?

kollokollo commented at 9:44 pm on November 27, 2017: none

No, they are all in different blocks. As the number of confirmations say. e.g. 1836 367187, (ehemals) 365876 (ehemals) 2145 (lieferando) 366627 (ehemals) 358927(ehemals) 365017(ehemals) 365967 (n/a)

Not even the order is chronological.

kollokollo commented at 6:50 am on December 5, 2017: none

I have reproduced this one other time with a different wallet: My diagnosis is: New Entries in the list of transactions are made always with a timestamp not older than the last transaction which was really send (or received) from the client. So all transactions which are recognized during a rescan (due to wallet change or import of a priv key) will not get their real timestamp if they are older than the latest transaction sent by the core client. However, if you have not (yet) send or received any transaction with the running core client so far, private keys are imported correctly. Also exchanging wallet.dat woked without noticable problems. The problem starts with the first transaction send. I hope this observation helps fixing it.

maflcko commented at 8:58 pm on December 15, 2017: member

Link to presumably related issue: #6662

BashCo commented at 11:25 pm on December 17, 2017: none

I’m experiencing the same issue with v0.15.1 on Mac OS X.

Perhaps coincidentally, the incorrect dates on my imported addresses are the same as @kollokollo, although the times are different: 2017-12-11T21:49:20

All the transactions associated with those imported addresses were confirmed in blocks prior to 2017-12-11. Any suggestions on how to mitigate or work around this issue would be appreciated.

achow101 commented at 8:26 pm on December 25, 2017: member

The issue looks like it is with this case:

https://github.com/bitcoin/bitcoin/blob/df91e11ae1e9d7af55a549b597a73d01e3a646c7/src/wallet/wallet.cpp#L3652-L3655

achow101 commented at 1:02 am on December 26, 2017: member

So investigating this issue a bit more shows that the reason this happens is because of the way that the smart time works and this is intended behavior. As explained in #1393 (which added this behavior) the reason for having new transactions always have the same timestamp or later of the last transaction in the wallet is to preserve the order of listtransactions. But I’m sure there is some way we can keep that ordering but preserve the time of a transaction.

luke-jr commented at 3:33 am on December 26, 2017: member

Rather, to keep time monotonic. Ordering is separate from time already.

achow101 commented at 3:43 am on December 26, 2017: member

Does time need to be monotonic though? For what reasons?

On December 25, 2017 10:34:11 PM Luke Dashjr notifications@github.com wrote:

Rather, to keep time monotonic. Ordering is separate from time already.

– You are receiving this because you commented. Reply to this email directly or view it on GitHub: #11703 (comment)

Nargren commented at 11:25 am on January 6, 2018: none

I am also having this issue with v0.15.1 on both Windows and Ubuntu.

I share the observation of @kollokollo, where a recent transaction causes false timestamps for (some) older transactions.

jb55 commented at 6:11 pm on November 27, 2020: contributor

Nov27-100942

I think I’m hitting this issue? or is this something else? I just did a rescan on latest master as of yesterday and the dates seem wrong at a certain point (after the 2017 one). this is a descriptor wallet.

Perhaps I should try applying #12024 ?

kouloumos commented at 7:50 pm on August 4, 2022: contributor

As has already pointed out, this issue is related specifically to this logic https://github.com/bitcoin/bitcoin/blob/df91e11ae1e9d7af55a549b597a73d01e3a646c7/src/wallet/wallet.cpp#L3652-L3655 #20591 has since added this additional logic to fix this issue *“receiving a transaction” is probably a typo, it should say “receiving a block”. https://github.com/bitcoin/bitcoin/blob/2c3115d4f568b2719daa44d8eb2504a8cd7691fe/src/wallet/wallet.cpp#L2604-L2605 The wording is like this because block rescan processing and realtime processing share the same logic (see caller graph of ComputeTimeSmart). The rescanning_old_block flag is what now differentiates between the two processes https://github.com/bitcoin/bitcoin/blob/2c3115d4f568b2719daa44d8eb2504a8cd7691fe/src/wallet/wallet.cpp#L2633-L2635

wallet_transactiontime_rescan.py is also testing against this scenario.

willcl-ark commented at 10:09 pm on November 22, 2022: contributor

Should this also be closed by #20591 like #6662 was? The fixed true value during ScanForWalletTransactions() here: https://github.com/bitcoin/bitcoin/blob/38d06e1561013f4ca845fd5ba6ffcc64de67f9c0/src/wallet/wallet.cpp#L1887 … would apply equally to privkeys imported to legacy wallets too.

maflcko commented at 10:32 pm on November 22, 2022: member

Ok, closing for now. Can be reopened if the fix didn’t work.

maflcko closed this on Nov 22, 2022

bitcoin locked this on Nov 22, 2023