Bug with timestamps on Bitcoin-Qt client for OS X

[BitcoinGirl325]

Hi there,

I believe that I have discovered a bug with timestamps in the Bitcoin-Qt client for OS X. I have attached a screenshot below, along with an explanation of the bug. (I am not a programmer, so I don't have the skills to fix this bug myself… I can only report it.)

I launched my Bitcoin-Qt client (version 0.9.2.1) on OS X 10.8.5 a few days ago, and the Bitcoin-Qt client started the process of synchronizing to the network and "catching up" to all the missed transactions since the last time I had launched Bitcoin-Qt.

However, BEFORE the synchronization finished getting completely up-to-date, I decided to send coins to someone's Bitcoin address (transaction ID 413452e88a2b3b5155c26b62c38e53e3924e6c4d41fb3a8ecaeda269e6f5e4b8-000). I did this at exactly 7/29/14 00:58. In other words, I sent these coins BEFORE the green checkmark icon appeared in the lower right corner of the Bitcoin-Qt client. I sent these coins while the "syncing icon" appeared in the lower right corner of the client.

The coins were sent successfully.

However, after these coins were successfully sent, my Bitcoin-Qt client still needed about 10 minutes to finish synchronizing to the Bitcoin network, so that it could "catch up" on all the missed transactions from the previous days.

Sure enough, a whole bunch of incoming "receive transactions" started showing up in my client. These were coins that had been sent to me from the previous days, and my Bitcoin-Qt client was displaying these transactions for the very first time to me.

BUT THIS IS WHERE THE BUG CROPS UP: All of these "receive transactions" came in with the same exact timestamp as my "send transaction" mentioned above. All of these receive transactions were ACTUALLY received by the Bitcoin network on 7/28/14 (or earlier), yet ALL of these transactions are showing up in my Bitcoin-Qt client with the same timestamp of 7/29/14 00:58… the same exact timestamp as my send transaction mentioned above.

If you take a look at the screenshot below, you'll see this bug in action. You'll notice that every single "receive transaction" has the exact same timestamp as the "send transaction", even though those timestamps aren't accurate. All of those receive transactions actually took place BEFORE the listed timestamp.

For example:
The top 0.002 BTC transaction is transaction ID c0257b7505d7a7f424593bc8f40c1352cb514c686fe6a9545790c200e12294c2.
The 0.0017 BTC transaction is transaction ID d50482a4c646454aff15c37cd5afdb5c3d30bcf92513c1e65c55d5286eebdef0.
The 0.0014385 BTC transaction is transaction ID e5086f06d1b3420eb020bc0c8b04a6d1c274a0f6c90c430d90207e0d4cb9f4e0.

You'll notice that all of those transactions were actually received BEFORE 7/29/14 00:58, but they are showing up in my client as 7/29/14 00:58.

Thanks!!

[1715585381]

1715585381

[1715585381]

1715585381

[1715585381]

1715585381

[1715585381]

1715585381

[1715585381]

1715585381

[theymos]

This is expected behavior. Bitcoin Core won't ever reorder your transactions, as this could cause you to miss some transactions (especially for automated usage of bitcoind). Therefore, if any transaction apparently occurs before your latest transaction, then its time will instead be set equal to your latest transaction.

[BitcoinGirl325]

This is expected behavior. Bitcoin Core won't ever reorder your transactions, as this could cause you to miss some transactions (especially for automated usage of bitcoind). Therefore, if any transaction apparently occurs before your latest transaction, then its time will instead be set equal to your latest transaction.

Ah, interesting. So it seems like I created this problem by sending coins before my client was fully synchronized. Would you mind explaining how a reordering of transactions could potentially cause someone to miss transactions? I'm just trying to wrap my head around this, because this is all so new to me.

Also, if I imported my private keys into another app (such as MultiBit, for example), I assume that the other app would pull all the "correct timestamps" from one of the Bitcoin nodes on the network, because that other app would be starting completely from scratch?

Thanks!!

[DeathAndTaxes]

Also, if I imported my private keys into another app (such as MultiBit, for example), I assume that the other app would pull all the "correct timestamps" from one of the Bitcoin nodes on the network, because that other app would be starting completely from scratch?

There is no timestamp in the transaction itself.  The timestamp is client level data that indicates when the client first "saw" the transaction.  The timestamps may not be the same for all nodes as different nodes may see the txn at different times.

[BitcoinGirl325]

Also, if I imported my private keys into another app (such as MultiBit, for example), I assume that the other app would pull all the "correct timestamps" from one of the Bitcoin nodes on the network, because that other app would be starting completely from scratch?

There is no timestamp in the transaction itself.  The timestamp is client level data that indicates when the client first "saw" the transaction.  The timestamps may not be the same for all nodes as different nodes may see the txn at different times.

A-ha! This explains everything!! Thank you for catching me up to speed on how all of this works!

[theymos]

Ah, interesting. So it seems like I created this problem by sending coins before my client was fully synchronized. Would you mind explaining how a reordering of transactions could potentially cause someone to miss transactions? I'm just trying to wrap my head around this, because this is all so new to me.

Also, if I imported my private keys into another app (such as MultiBit, for example), I assume that the other app would pull all the "correct timestamps" from one of the Bitcoin nodes on the network, because that other app would be starting completely from scratch?

If a new transaction appeared a ways down in the transaction list so that you'd have to scroll down to see it, then you might not notice it. More likely to cause problems is the fact that automated scripts often poll listtransactions and go back only until they see a transaction that they've already seen before.

Bitcoin Core used to use the most accurate time available for each transaction, but the reordering caused problems, so it was changed to the current behavior.

If you start from scratch, the client will use the timestamp of the block that contains the transaction. At best, this is accurate to within a few hours, and it can in some cases be off by days from when the transaction was actually sent.

[BitcoinGirl325]

Thank you for this information!