Bitcoin Forum
September 27, 2016, 06:54:41 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: What could be the transition plan to Y2038 compliant Bitcoin? (it already is)  (Read 3776 times)
throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 09, 2010, 12:25:35 PM
 #1

Or will it suddenly die then?
1475002481
Hero Member
*
Offline Offline

Posts: 1475002481

View Profile Personal Message (Offline)

Ignore
1475002481
Reply with quote  #2

1475002481
Report to moderator
1475002481
Hero Member
*
Offline Offline

Posts: 1475002481

View Profile Personal Message (Offline)

Ignore
1475002481
Reply with quote  #2

1475002481
Report to moderator
1475002481
Hero Member
*
Offline Offline

Posts: 1475002481

View Profile Personal Message (Offline)

Ignore
1475002481
Reply with quote  #2

1475002481
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 09, 2010, 12:34:56 PM
 #2

As far as I can read C++, Bitcoin implementation stores timestamps as unsigned integers
and block timestamp is a part of binary block format, of which a hash is computed.
Since blocks are chained and the previous block is referenced in the current by it's hash,
you cannot simply recompile the client with 64bit timestamps.
You will need to recompute the whole chain, is that an option?
Or we need to propose some transition plan to another binary block format.

Or, I am wrong and everybody should relax.

What do you think?
martin
Full Member
***
Offline Offline

Activity: 150



View Profile WWW
August 09, 2010, 12:43:49 PM
 #3

I believe you would need a client which understood the old time format and the new one. At a certain block number all clients would switch over to the new timestamp system, old blocks would stay as they are, people with old versions of the software would suddenly find that they could not submit any transactions or create any blocks.

throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 09, 2010, 01:30:25 PM
 #4

I believe you would need a client which understood the old time format and the new one. At a certain block number all clients would switch over to the new timestamp system, old blocks would stay as they are, people with old versions of the software would suddenly find that they could not submit any transactions or create any blocks.

Great.

Everybody, how do you think, is it time to bother on implementing that plan or we should wait for something to happen?
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
August 09, 2010, 03:39:14 PM
 #5

Timestamps are already stored as uint64s. At least, that's how they're transmitted on the network.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
August 09, 2010, 05:39:03 PM
 #6

Timestamps are already stored as uint64s. At least, that's how they're transmitted on the network.

main.cpp:                unsigned int nTime;


in the block headers. Thats 32 bits if you don't know.

jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
August 09, 2010, 06:18:23 PM
 #7


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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
August 09, 2010, 07:58:09 PM
 #8

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.


"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
August 09, 2010, 08:12:02 PM
 #9

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 Smiley

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
August 09, 2010, 08:13:26 PM
 #10

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.
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
August 10, 2010, 02:36:13 AM
 #11

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.
Why are we using uint64 in Version but 32-bit integers in everything else?

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 10, 2010, 05:44:12 AM
 #12

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.

I have a better idea for timestamps, whatever their underlying type is, for the purposes of calculating the hash,
convert them to the string representation of the number of seconds since the epoch (I hope that moment will not change
after a century).
semyazza
Sr. Member
****
Offline Offline

Activity: 339


View Profile
August 13, 2010, 12:20:15 AM
 #13

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.

lol. This made me laugh. Yes, please point these out in the next 25 years. If you're considerate, make it 24 so he has a year to make the change Cheesy

+1 on the laugh
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!