Luke-Jr (OP)
Legendary
 Offline
Activity: 2576
Merit: 1186
|
 |
December 14, 2011, 12:24:48 AM |
|
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... 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? |
|
|
|
|
|
|
|
|
|
|
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
Gavin Andresen
Legendary
Offline
Activity: 1652
Merit: 2216
Chief Scientist
|
|
December 14, 2011, 12:31:49 AM |
|
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... |
How often do you get the chance to work on a potentially world-changing project?
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
December 14, 2011, 12:35:42 AM |
|
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. |
|
|
|
nelisky
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
December 14, 2011, 10: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.
|
|
|
|
|
netrin
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
December 15, 2011, 04: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. 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. |
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
December 15, 2011, 04: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? I meant the JSON-RPC method, which software kindof needs to have in order. 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...  |
|
|
|
netrin
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
December 15, 2011, 04:59:10 AM |
|
Oh, then I would still suggest both local and network timestamps to normalize future wallet mergers.
|
|
|
|
|
Hawkix
|
|
January 05, 2012, 08: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?
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
January 05, 2012, 08:32:41 PM |
|
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... |
|
|
|
|
