pull down to refresh
0 sats \ 1 reply \ @2big2fail 18 Aug 2022
has there been any proposed solutions for this or thoughts as to why 32bit ntime was used?
for example recompiling has been suggested
reply
0 sats \ 0 replies \ @2big2fail 18 Aug 2022
https://github.com/bitcoin/bitcoin/issues/21356
reply
0 sats \ 2 replies \ @Brunswick 18 Aug 2022
Two possible outcomes: either humanity learns to get along to fix this small issue, or humanity never adopts bitcoin and we blow ourselves up long before the bug is a problem.
Let's not forget we still have the 32 bit unix timestamp bug in 2038 that lies in wait in computers that likely will never be retired nor updated before then. Hopefully it'll only effect obsolete equipment BlackBerry phones and other QNX based systems
reply
0 sats \ 1 reply \ @rijndael 18 Aug 2022
We'll end up fixing it in a hard fork
reply
0 sats \ 0 replies \ @Brunswick 18 Aug 2022
I love how this issue was shutdown by a bunch of dickwads rather than addressing the concern.
https://github.com/bitcoin/bitcoin/issues/18182
It appears the 32bit problem only applies to a computation and proper casting of types when working with the clock. The nTime variable itself shouldn't require a hard fork because it only stores the differential time over a two week period.
https://github.com/bitcoin/bitcoin/issues/21356#issuecomment-1126880786
reply
0 sats \ 0 replies \ @Wil 18 Aug 2022
Yup Bitcoin will stop working in 2106 once it overflows.
reply