(context post by jgarzik)

It seems to be a crazy mix…

CWalletKey(main.h): 64-bit Rest of main.h, including in-memory block/txn objects: 32-bit Internal main.cpp calculations: 64-bit Network(version): 64-bit Network(addr): 32-bit Network(getblock): 32-bit Network(submitorder): 32-bit

At a minimum, there are plenty of 32-bit time variables that clearly need changing to 64-bit.

I’m not a programmer, but I have doubts that any of those 32 bit variables are subject to rolling over antime near 2038. My understanding, however limited it may be, is that the timestamp of the blockchain is relative only to it’s position within the chain, and not subject to any such limitations. I’m sure that the two week difficulty calculations require an accurate count of seconds, but at worst, that would just throw off the calculations for the two weeks around the rollover in 2038. And since there is a limit to just how much the difficulty may change in any two week period, even that isn’t particularly crucial.

[Deleted] Quote from: davidonpda on August 09, 2010, 08:07:26 PM

The problem with the time stamps, is a unix time stamp as a 32 bit integer WILL overflow in 2038. I am a programmer, but you can find more info on it by googling unix time problem or 2038

I understand the Y2038 problem from a layman’s perspective. My point was that, I doubted that a Y2038 problem exists within the structure of bitcoin. Since the timestamp is relative only to a particular position within the blockchain, there is no reason that a client should require an accurate timestamp within the block. And then, what would that be? GMT? I’m pretty sure that my client is doing fine with local time. If that could be getting any successful blocks rejected, let me know, please.

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

There should not be any signed int.  If you’ve found a signed int somewhere, please tell me (within the next 25 years please) and I’ll change it to unsigned int.