Bitcoin Forum
December 08, 2016, 12:23:29 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Timestamp wrap around  (Read 1911 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
July 06, 2011, 11:50:04 AM
 #1

Is there an official way to handle this?

The current time counts in seconds since 1970 and is 32 bits.  This gives it a max of 2^32 seconds = 4294967296 = 136 years, if it is an unsigned number.  That works out as 2106.

Since the default client is also the reference client.  It would be worth adding a defined way of handling the wrap around.

The rule for blocks is

1) timestamp must not be smaller than the median of the last 10 blocks
2) timestamp must not be more than 2 hours into the future

The first rule is to prevent time traveling backwards and is purely based on the block chain.  All past blocks can be verified and they will all easily meet rule 2.

When a miner creates a block, he can easily make sure he meets both the rules by making sure his timestamp is at least as high as the median of the last 10 blocks.

The 32 bit timestamp in many computers is actually a signed number, so it can really only go up to 68 years (2035).

The spec could define a wrap around event. 

Assuming unsigned number, if the timestamp for a block is less than 0xC0000000 (-MAX_TIME/2) and the previous block was greater than 0x40000000 (MAX_TIME/2), then wrap around shall be considered to have happened. 

2^32 should be added to all timestamps for that block and all later blocks to work out the actual time.

Real timestamp = (number of wrap arounds before this block) * 2^32 + (unsigned int)timestamp

This would mean that the protocol wouldn't need to be changed and the 2 rules could be kept unchanged.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1481156609
Hero Member
*
Offline Offline

Posts: 1481156609

View Profile Personal Message (Offline)

Ignore
1481156609
Reply with quote  #2

1481156609
Report to moderator
1481156609
Hero Member
*
Offline Offline

Posts: 1481156609

View Profile Personal Message (Offline)

Ignore
1481156609
Reply with quote  #2

1481156609
Report to moderator
1481156609
Hero Member
*
Offline Offline

Posts: 1481156609

View Profile Personal Message (Offline)

Ignore
1481156609
Reply with quote  #2

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

Posts: 1481156609

View Profile Personal Message (Offline)

Ignore
1481156609
Reply with quote  #2

1481156609
Report to moderator
1481156609
Hero Member
*
Offline Offline

Posts: 1481156609

View Profile Personal Message (Offline)

Ignore
1481156609
Reply with quote  #2

1481156609
Report to moderator
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 06, 2011, 04:11:10 PM
 #2

It's a good idea to read the source code before making posts like this.

Changing signed 32-bit to unsigned 32-bit is at best a stopgap measure for solving the Year 2038 problem, and Bitcoin wisely did not do this.

Bitcoin already uses signed 64-bit timestamps internally. This means it's good for a few billion years. It only converts to time_t for displaying to the user. Some parts of the code probably need to be looked at again, though.

The real problem that needs to be solved is that, even on 64-bit operating systems, time_t is still a 32-bit value. This is not specific to Bitcoin.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
July 06, 2011, 04:30:47 PM
 #3

It's a good idea to read the source code before making posts like this.

Hmm, I am pretty sure I didn't suggest switching to 32 bit unsigned.  I could comment with something like "It's a good idea to read a post before replying to it" Smiley.

Quote
The real problem that needs to be solved is that, even on 64-bit operating systems, time_t is still a 32-bit value. This is not specific to Bitcoin.

Actually, I think the real problem is that the block chain only has 32 bits for the timestamp.  That is what my suggestion was related to.

That should be set to handle wrap around, so that future clients which meet the spec will be compliant.

The main point is that since it takes 140 years for a wrap around event and blocks are created every 10 minutes, it would be easy to have the clients detect wrap around.

So, something like

Block 1500000:
Timestamp = 2147483448
Actual = 2147483448

Block 1500001:
Wrap detected
Timestamp = -2147483248
Actual = -2147483848 + 2^32 = 2147484048

This allows the current protocol to be used without change.  The clients would need to be updated anyway.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
July 06, 2011, 05:04:20 PM
 #4

Other problems (such as weakening crypto) will force a protocol redesign before then. Then we can use a real high-precision number instead of a hack. Satoshi said:

unsigned int is good until 2106.  Surely the network will have to be totally revamped at least once by then.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 06, 2011, 05:21:27 PM
 #5

It's a good idea to read the source code before making posts like this.

Hmm, I am pretty sure I didn't suggest switching to 32 bit unsigned.  I could comment with something like "It's a good idea to read a post before replying to it" Smiley.

But that's pretty much exactly what you suggested, twice now.

Quote
The real problem that needs to be solved is that, even on 64-bit operating systems, time_t is still a 32-bit value. This is not specific to Bitcoin.

Actually, I think the real problem is that the block chain only has 32 bits for the timestamp.  That is what my suggestion was related to.

Oh, I see it being stored as 32 bits on disk. Looks like it's 32 bits on the network as well. This is a serious oversight and needs to be fixed, not merely worked around.

That should be set to handle wrap around, so that future clients which meet the spec will be compliant.

The main point is that since it takes 140 years for a wrap around event and blocks are created every 10 minutes, it would be easy to have the clients detect wrap around.

So, something like

Block 1500000:
Timestamp = 2147483448
Actual = 2147483448

Block 1500001:
Wrap detected
Timestamp = -2147483248
Actual = -2147483848 + 2^32 = 2147484048

This allows the current protocol to be used without change.  The clients would need to be updated anyway.

This workaround you've proposed effectively makes it an unsigned 32-bit integer. Sure, this buys you another 140 years, but as a solution it's rather inelegant. Especially when Bitcoin is already handling times in 64-bit format (except for the serious omissions noted above).

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
July 06, 2011, 06:50:06 PM
 #6

Oh, I see it being stored as 32 bits on disk. Looks like it's 32 bits on the network as well. This is a serious oversight and needs to be fixed, not merely worked around.

It's not an oversight. The headers have a version field for a reason.

Changing to 64 bit for that field would inflate the block headers (something all lite clients need) by 5% for _null_ value because we'll almost certainly need to change to a new version or other reasons (most obviously for hash function upgrades) long before 32bit block timestamps become an issue.


error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 06, 2011, 07:27:55 PM
 #7

Oh, I see it being stored as 32 bits on disk. Looks like it's 32 bits on the network as well. This is a serious oversight and needs to be fixed, not merely worked around.

It's not an oversight. The headers have a version field for a reason.

Changing to 64 bit for that field would inflate the block headers (something all lite clients need) by 5% for _null_ value because we'll almost certainly need to change to a new version or other reasons (most obviously for hash function upgrades) long before 32bit block timestamps become an issue.

I didn't say it needed to be fixed TOMORROW. Smiley Maybe by 2030 or so.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
July 06, 2011, 08:15:53 PM
 #8

This workaround you've proposed effectively makes it an unsigned 32-bit integer. Sure, this buys you another 140 years, but as a solution it's rather inelegant. Especially when Bitcoin is already handling times in 64-bit format (except for the serious omissions noted above).

I meant that it could wrap around again and again.  I did intend that it went from +70 years to -70 years, rather than switch to unsigned, but it doesn't really make much difference what you call it.

Unless 2 blocks are created more than 70 years apart, it is possible to figure out if a wrap has occurred by comparing the block before and after the wrap.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
July 07, 2011, 03:36:06 AM
 #9

Unless 2 consecutive blocks are created more than 70 years apart, it is possible to figure out if a wrap has occurred by comparing the block before and after the wrap.

Clarified that for ya.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
July 07, 2011, 08:13:27 AM
 #10

Clarified that for ya.

Yeah, thanks Smiley.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
TeraPool
Jr. Member
*
Offline Offline

Activity: 42


View Profile
July 07, 2011, 04:40:24 PM
 #11

Ok so basically everybody who uses bitcoin will have to upgrade their code before 2030ish and all block headers will then start with version 2 instead of version 1?

We don't need a new block chain for that?

theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
July 07, 2011, 04:46:55 PM
 #12

Ok so basically everybody who uses bitcoin will have to upgrade their code before 2030ish and all block headers will then start with version 2 instead of version 1?

We don't need a new block chain for that?
An upgrade will be necessary sometime before 2106.

The block format will change, but the old blocks will remain valid.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
July 07, 2011, 04:51:36 PM
 #13

I don't see the problem. As long as two bitcoin block are not allowed to be more than 70.4 years apart in time, 32 bit timestamps in the block header is enough to assign an exact (64 bit) timestamp to each block.

Just think of bitcoin as actually working with 64-bit arithmetic for time, but only writing the lower 32 bits in block headers. The upper 32 bits can always be inferred from the chain.

If blocks would only be allowed to go 70 minutes back in time, and max 17 hours forward, 16 bits would even suffice.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
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!