Is there a plan in which future version of Bitcoin client this date issue will be fixed (back to block creation date)?
Patches welcome. But not just a revert... 
Topic: Displayed transaction timestamps (Was: Please help sanity test: version 0.5.1) (Read 2737 times)
January 05, 2012, 04:32:41 PM
January 05, 2012, 04:23:53 PM
Is there a plan in which future version of Bitcoin client this date issue will be fixed (back to block creation date)?
Its pretty annoying. For example, friend of mine called me that I promised to send BTC last week, but *obviously* I had to do that just few moments before he run his client.
Even if fixed, the existing received transactions will be forever fixed with "bad" time in the wallet, won't they?
Its pretty annoying. For example, friend of mine called me that I promised to send BTC last week, but *obviously* I had to do that just few moments before he run his client.
Even if fixed, the existing received transactions will be forever fixed with "bad" time in the wallet, won't they?
December 15, 2011, 12:59:10 AM
Oh, then I would still suggest both local and network timestamps to normalize future wallet mergers.
December 15, 2011, 12:56:19 AM
Some older versions used that time until it was confirmed, and then changed the timestamp to the block time. This caused listtransactions to change order.
List transactions - the balance sheet in the local client?
Could the local sent timestamp or autoincremented index be stored separately from the block timestamps?
I don't care what the GUIs do. They can display the block timestamp, while sorting by the "list-canonical timestamp" suggested in this thread... 
December 15, 2011, 12:47:47 AM
I would expect confirmed transaction to use a canonical timestamp (agreed by the block chain) and would expect an unconfirmed transaction to have an estimated but similarly unconfirmed timestamp.
List transactions - the balance sheet in the local client? Could the local sent timestamp or autoincremented index be stored separately from the block timestamps?
For whom is this a requirement? I for one, would prefer my data was in consistent agreement with the rest of the network whenever possible.
Some older versions used that time until it was confirmed, and then changed the timestamp to the block time. This caused listtransactions to change order.
List transactions - the balance sheet in the local client? Could the local sent timestamp or autoincremented index be stored separately from the block timestamps?
Requirements:
- The timestamp shown for a transaction should never change.
For whom is this a requirement? I for one, would prefer my data was in consistent agreement with the rest of the network whenever possible.
December 14, 2011, 06:04:50 PM
This might be a bit off, as I'm not sure about the implications, but what about a 'not known' timestamp, always displayed on top by first come order? It could be shown as current timestamp (read, changes as seconds pass) which would be cool and confusing, but most simply not showing any timestamp until transactions are assigned to a block and using the block time from then on?
Outbound transactions, the ones we send, could benefit from keeping the actual transaction creation timestamp, but even then I'd be plenty satisfied if I knew the timestamp of the block in which they got included.
Outbound transactions, the ones we send, could benefit from keeping the actual transaction creation timestamp, but even then I'd be plenty satisfied if I knew the timestamp of the block in which they got included.
December 13, 2011, 08:35:42 PM
And coinbase transactions should be assigned the block timestamp.
This recently created a problem for Eligius. I think it needs to follow the same rules as other formerly-unknown transactions in the block. 
December 13, 2011, 08:31:49 PM
Anything I'm missing here?
... if you're sending a transaction, then its timestamp should be the time it is sent.And coinbase transactions should be assigned the block timestamp.
I think. It is odd that different machines may assign the same transaction different timestamps...
December 13, 2011, 08:24:48 PM
A little off topic, but when did the transaction dates stop being shown from the block timestamp and started being the timestamp at which the block was received? This bugs me because I do mental averages of generation, and only start the client every now and then, which then proceeds to download the blockchain pinning all new transactions under more or less the same date and time, i.e. now.
This still happens with 0.5.1, don't know if a bug or feature, it started somewhere on the 0.4 series and I always forget to report...
It is actually the time that the transaction was received. Some older versions used that time until it was confirmed, and then changed the timestamp to the block time. This caused listtransactions to change order. I agree this logic needs reworking to be sane in all scenarios. Perhaps something along these lines...This still happens with 0.5.1, don't know if a bug or feature, it started somewhere on the 0.4 series and I always forget to report...
Requirements:
- The timestamp shown for a transaction should never change.
- New transactions should always have a timestamp no earlier than the transactions accounted for before it.
- THEREFORE, new transactions should never have future timestamps.
- listtransactions should preserve the order of transactions added.
Logic:
- If receiving a transaction outside a block, assign its timestamp to the current time.
- If receiving a block with a future timestamp, assign all its (not already known) transactions' timestamps to the current time.
- If receiving a block with a past timestamp, before the most recent known transaction (that we care about), assign all its (not already known) transactions' timestamps to the same timestamp as that most-recent-known transaction.
- If receiving a block with a past timestamp, but after the most recent known transaction, assign all its (not already known) transactions' timestamps to the block time.
Additionally, it might make sense to add 'first_seen' and 'block_time' to the information.
Anything I'm missing here?
Jump to: