Bitcoin Forum
March 29, 2020, 02:29:54 AM
 News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 Home Help Search Login Register More
 Pages: [1]
 Author Topic: Timestamp wrap around  (Read 2125 times)
TierNolan
Legendary

Offline

Activity: 1232
Merit: 1005

 July 06, 2011, 11:50:04 AM

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
1585448994
Hero Member

Offline

Posts: 1585448994

Ignore
 1585448994

1585448994
 Report to moderator
1585448994
Hero Member

Offline

Posts: 1585448994

Ignore
 1585448994

1585448994
 Report to moderator
1585448994
Hero Member

Offline

Posts: 1585448994

Ignore
 1585448994

1585448994
 Report to moderator
Roullete Flip Duels Bubble Player vs B2 Player vs Player Player vs B2 Supports Lightning Network The Social Gambling Games Play Now
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1585448994
Hero Member

Offline

Posts: 1585448994

Ignore
 1585448994

1585448994
 Report to moderator
1585448994
Hero Member

Offline

Posts: 1585448994

Ignore
 1585448994

1585448994
 Report to moderator
1585448994
Hero Member

Offline

Posts: 1585448994

Ignore
 1585448994

1585448994
 Report to moderator
error
Hero Member

Offline

Activity: 588
Merit: 500

 July 06, 2011, 04:11:10 PM

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.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
TierNolan
Legendary

Offline

Activity: 1232
Merit: 1005

 July 06, 2011, 04:30:47 PM

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

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
Legendary

Offline

Activity: 3710
Merit: 7647

 July 06, 2011, 05:04:20 PM

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.

error
Hero Member

Offline

Activity: 588
Merit: 500

 July 06, 2011, 05:21:27 PM

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

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

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
gmaxwell
Moderator
Legendary

Offline

Activity: 3010
Merit: 3392

 July 06, 2011, 06:50:06 PM

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

Activity: 588
Merit: 500

 July 06, 2011, 07:27:55 PM

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. Maybe by 2030 or so.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
TierNolan
Legendary

Offline

Activity: 1232
Merit: 1005

 July 06, 2011, 08:15:53 PM

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

Activity: 1302
Merit: 1001

 July 07, 2011, 03:36:06 AM

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
TierNolan
Legendary

Offline

Activity: 1232
Merit: 1005

 July 07, 2011, 08:13:27 AM

Clarified that for ya.

Yeah, thanks .

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
TeraPool
Newbie

Offline

Activity: 42
Merit: 0

 July 07, 2011, 04:40:24 PM

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
Legendary

Offline

Activity: 3710
Merit: 7647

 July 07, 2011, 04:46:55 PM

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.

Pieter Wuille
Legendary

Offline

Activity: 1064
Merit: 1036

 July 07, 2011, 04:51:36 PM

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.

I do Bitcoin stuff.
 Pages: [1]