Bitcoin Forum
October 21, 2017, 07:44:46 PM
 News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 Home Help Search Donate Login Register
 Pages: [1]
 Author Topic: Timestamp wrap around  (Read 2056 times)
TierNolan
Legendary

Offline

Activity: 1120

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

Offline

Posts: 1508615086

Ignore
 1508615086

1508615086
 Report to moderator
1508615086
Hero Member

Offline

Posts: 1508615086

Ignore
 1508615086

1508615086
 Report to moderator
1508615086
Hero Member

Offline

Posts: 1508615086

Ignore
 1508615086

1508615086
 Report to moderator
According to NIST and ECRYPT II, the cryptographic algorithms used in Bitcoin are expected to be strong until at least 2030. (After that, it will not be too difficult to transition to different algorithms.)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508615086
Hero Member

Offline

Posts: 1508615086

Ignore
 1508615086

1508615086
 Report to moderator
1508615086
Hero Member

Offline

Posts: 1508615086

Ignore
 1508615086

1508615086
 Report to moderator
error
Hero Member

Offline

Activity: 574

 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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
TierNolan
Legendary

Offline

Activity: 1120

 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: 2814

 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: 574

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
gmaxwell
Moderator
Legendary

Offline

Activity: 2324

 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.

Bitcoin will not be compromised
error
Hero Member

Offline

Activity: 574

 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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
TierNolan
Legendary

Offline

Activity: 1120

 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

 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.

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

Activity: 1120

 July 07, 2011, 08:13:27 AM

Clarified that for ya.

Yeah, thanks .

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
TeraPool
Jr. Member

Offline

Activity: 42

 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: 2814

 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: 1050

 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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
 Pages: [1]
 « previous topic next topic »