Timestamp wrap around

[TierNolan]

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.

[1714834968]

1714834968

[1714834968]

1714834968

[1714834968]

1714834968

[error]

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.

[TierNolan]

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

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.

[theymos]

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]

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.

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

[gmaxwell]

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]

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.

[TierNolan]

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.

[kjj]

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.

[TierNolan]

Clarified that for ya.

Yeah, thanks .

[TeraPool]

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]

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]

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.