4 byte size limit for time in block header

[GGfien]

Sunday, February 7, 2106 6:28:14 AM is 4294967294 in UNIX. 4294967294 is the highest int that can fit within the 4 byte limit of timestamp portion of the blockheader.

If there is no room for the timestamp, and the timestamp has to be 5 bytes, how will bitcoin continue to create blocks?

My only thought is to have it reset to 0, but how would you even go about doing that without doing a hardfork? I really feel like this is a discussion we should having now rather than latter.

[DaveF]

This has been discussed many times here as recently as a couple of weeks ago:

https://bitcointalk.org/index.php?topic=5418910

It's a known problem, with several discussions in various places on how to fix it. Since it is 84 years off it's not a major concern. The general 2038 bug is probably going be more of an issue since in 80+ years almost nobody is going to be running an OS / software from this era, but there are still things being written today that will be running in 16 years.

-Dave

[GGfien]

This has been discussed many times here as recently as a couple of weeks ago:

https://bitcointalk.org/index.php?topic=5418910

It's a known problem, with several discussions in various places on how to fix it. Since it is 84 years off it's not a major concern. The general 2038 bug is probably going be more of an issue since in 80+ years almost nobody is going to be running an OS / software from this era, but there are still things being written today that will be running in 16 years.

-Dave

2038 bug? For signed integers yes; but not unsigned because it is only whole numbers, not negatives ones.

That bug wouldn't effect Bitcoin right?

[ABCbits]

My only thought is to have it reset to 0, but how would you even go about doing that without doing a hardfork?

Hardfork will be needed since node only accept block with 2 hours offset.

I really feel like this is a discussion we should having now rather than latter.

I disagree, year 2106 is 84 years eight from now and most of us won't live until then (unless live expectancy significant improved). There are more pressing concern such as full-RBF, quantum-resistant cryptography and block size.

[DaveF]

I disagree, year 2106 is 84 years eight from now and most of us won't live until then (unless live expectancy significant improved). There are more pressing concern such as full-RBF, quantum-resistant cryptography and block size.

I plan to live forever or die trying ;-)

But seriously, since it is going to cause so many issues on so many things it's a known and solvable problem.
Put it in a hardfork with some other things that will have to happen and set it be enforced so far in the future that nobody will even think about it. If it's released in 2075 with a 15 year wait to be enforced then you still have another 16 years for people to stop running old clients. And if you are running, what would be 30+ year old software at that point you get to upgrade.

-Dave

[GGfien]

My only thought is to have it reset to 0, but how would you even go about doing that without doing a hardfork?

Hardfork will be needed since node only accept block with 2 hours offset.

I really feel like this is a discussion we should having now rather than latter.

I disagree, year 2106 is 84 years eight from now and most of us won't live until then (unless live expectancy significant improved). There are more pressing concern such as full-RBF, quantum-resistant cryptography and block size.

yep... just found that 2 hour offset feature...

Also, you make a good point. Perhaps in the future there will have to be a mandatory hard fork that makes the hashing algo more difficult, updates the time to 64 bits over 32 bits, along with other things that may come up.

Question is, is a hard fork ethical? From a philosophical view, is it still Bitcoin at that point?

I disagree, year 2106 is 84 years eight from now and most of us won't live until then (unless live expectancy significant improved). There are more pressing concern such as full-RBF, quantum-resistant cryptography and block size.

I plan to live forever or die trying ;-)

But seriously, since it is going to cause so many issues on so many things it's a known and solvable problem.
Put it in a hardfork with some other things that will have to happen and set it be enforced so far in the future that nobody will even think about it. If it's released in 2075 with a 15 year wait to be enforced then you still have another 16 years for people to stop running old clients. And if you are running, what would be 30+ year old software at that point you get to upgrade.

-Dave

Yeah that's a good idea!

Having a waiting period of X amount of years would prove the code to be genuine and battle tested. I would suggest having the code updated in perhaps 2057 with mandatory upgrade by 2107 so that 50 years prior (2009-2057) Bitcoin was tested and we trust it, so in theory, if this fork also holds up for 50 years it could also be considered as a worthy.

In addition, I believe virtually everyone will be on the updated version after 50 years and that their computer's OS won't even be able to install the original Bitcoin Core v0.1. After thinking everything through, this really is the smallest problem Bitcoin really needs to overcome.

Mod note: Consecutive posts merged

[BlackHatCoiner]

Year 2106 is far away. Nonetheless, there's no problem with hard forking if it's objectively for the good of all Bitcoin users. On top of what DaveF said regarding scheduled changes, I will add that we can pack both hard forks into one; ECDLP will be undoubtedly solved at some point in the future (likely before 2106), so we could hard fork it once, and add both a quantum resistant algorithm and switch to 8 byte timestamps.