32Bit timestamps in the block headers?

[mustyoshi]

Why would Satoshi (group or indiv.) use 32 bit timestamps which would overflow before the last coin was designed to be minted?

The fix is simple, just up it to 64bit unsigned integers to represent the date.

[Come-from-Beyond]

Why would Satoshi (group or indiv.) use 32 bit timestamps which would overflow before the last coin was designed to be minted?

The fix is simple, just up it to 64bit unsigned integers to represent the date.

This problem will rise in 2100+ A.D. only.

[mustyoshi]

Why would Satoshi (group or indiv.) use 32 bit timestamps which would overflow before the last coin was designed to be minted?

The fix is simple, just up it to 64bit unsigned integers to represent the date.

This problem will rise in 2100+ A.D. only.

Which is 34 years before the reward is due to be zero. This is going to be a problem eventually, so why not fix it now?

[jackjack]

Why would Satoshi (group or indiv.) use 32 bit timestamps which would overflow before the last coin was designed to be minted?

The fix is simple, just up it to 64bit unsigned integers to represent the date.

This problem will rise in 2100+ A.D. only.

Which is 34 years before the reward is due to be zero. This is going to be a problem eventually, so why not fix it now?

Because everybody now complains about the blockchain being too big
Not exactly the right time to increase the size of headers (I know it won't be noticeable but you know how that works...)

[Come-from-Beyond]

Which is 34 years before the reward is due to be zero. This is going to be a problem eventually, so why not fix it now?

It's a low priority problem. If Gavin doesn't fix problems related to ever-growing blockchain, we won't face "year 2100 problem" at all.

[leijurv]

Maybe I'm missing something, but won't 32-bit timestamps overflow in 2038?
http://en.wikipedia.org/wiki/Year_2038_problem

[Caesium]

It's unsigned, so that buys a few extra years. See 'Solutions' in your wiki link, its mentioned there.

[Come-from-Beyond]

Maybe I'm missing something, but won't 32-bit timestamps overflow in 2038?
http://en.wikipedia.org/wiki/Year_2038_problem

In Bitcoin the timestamp is unsigned.

[etotheipi]

This is basically a non-issue.  Just interpret the timestamp as the lower 32-bits of an infinite timestamp.  It "wraps around" every 138 years, and it's pretty easy to figure out how many times it's wrapped since Bitcoin was created, so it's easy to convert the stored 32-bit value, into your own 64-bit value.

[leijurv]

This is basically a non-issue.  Just interpret the timestamp as the lower 32-bits of an infinite timestamp.  It "wraps around" every 138 years, and it's pretty easy to figure out how many times it's wrapped since Bitcoin was created, so it's easy to convert the stored 32-bit value, into your own 64-bit value.

+1

[TierNolan]

This is basically a non-issue.  Just interpret the timestamp as the lower 32-bits of an infinite timestamp.  It "wraps around" every 138 years, and it's pretty easy to figure out how many times it's wrapped since Bitcoin was created, so it's easy to convert the stored 32-bit value, into your own 64-bit value.

Right, in fact, they should define it exactly like that.  You work out the timestamp of a block so that it minimised the difference in time relative to the previous block.

This works unless blocks take decades to arrive.