Bitcoin Forum
September 23, 2017, 07:48:21 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Displayed transaction timestamps (Was: Please help sanity test: version 0.5.1)  (Read 2579 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2240



View Profile
December 14, 2011, 12:24:48 AM
 #1

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?

1506152901
Hero Member
*
Offline Offline

Posts: 1506152901

View Profile Personal Message (Offline)

Ignore
1506152901
Reply with quote  #2

1506152901
Report to moderator
1506152901
Hero Member
*
Offline Offline

Posts: 1506152901

View Profile Personal Message (Offline)

Ignore
1506152901
Reply with quote  #2

1506152901
Report to moderator
1506152901
Hero Member
*
Offline Offline

Posts: 1506152901

View Profile Personal Message (Offline)

Ignore
1506152901
Reply with quote  #2

1506152901
Report to moderator
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1506152901
Hero Member
*
Offline Offline

Posts: 1506152901

View Profile Personal Message (Offline)

Ignore
1506152901
Reply with quote  #2

1506152901
Report to moderator
1506152901
Hero Member
*
Offline Offline

Posts: 1506152901

View Profile Personal Message (Offline)

Ignore
1506152901
Reply with quote  #2

1506152901
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 14, 2011, 12:31:49 AM
 #2

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
Legendary
*
expert
Offline Offline

Activity: 2240



View Profile
December 14, 2011, 12:35:42 AM
 #3

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 Offline

Activity: 1554


View Profile
December 14, 2011, 10:04:50 PM
 #4

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 Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 15, 2011, 04:47:47 AM
 #5

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.

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2240



View Profile
December 15, 2011, 04:56:19 AM
 #6

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... Wink

netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 15, 2011, 04:59:10 AM
 #7

Oh, then I would still suggest both local and network timestamps to normalize future wallet mergers.

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
Hawkix
Hero Member
*****
Offline Offline

Activity: 521



View Profile WWW
January 05, 2012, 08:23:53 PM
 #8

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?

Donations: 1Hawkix7GHym6SM98ii5vSHHShA3FUgpV6
http://btcportal.net/ - All about Bitcoin - coming soon!
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2240



View Profile
January 05, 2012, 08:32:41 PM
 #9

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...

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!