Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-18 Thread yanmaani--- via bitcoin-dev
Well, it's the right word. If you're going to do a hardfork by changing the timestamp definition, you're already doing a hardfork. At that point, you've already crossed the Rubicon and might as well put in any other necessary changes (e.g. to transaction locking), because it will be as much of

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-18 Thread damian--- via bitcoin-dev
Good Afternoon, I am certain that as soon as we identify solutions they should be implemented. Basic life skills assert that procrastination is always a form of failure, where we could have realised and accomplished further yet we waited and in our present state could not ascertain what was in

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-17 Thread Kate Salazar via bitcoin-dev
Hi yanmaani On Sun, Oct 17, 2021 at 5:28 PM yanmaani--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What, no. The `k` value is calculated implicitly, because there's only > one value of it that could ever be valid - if `k` is 1 too small, we're > 70 years too far back, and t

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-17 Thread yanmaani--- via bitcoin-dev
What, no. The `k` value is calculated implicitly, because there's only one value of it that could ever be valid - if `k` is 1 too small, we're 70 years too far back, and then the block will violate median of last 11. If `k` is 1 too large, we're 70 years too far in the future, then the block wi

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-17 Thread Kate Salazar via bitcoin-dev
There is a hard fork wishlist: https://en.bitcoin.it/wiki/Hardfork_Wishlist Note last update is somewhat old. Cheers. On Sat, Oct 16, 2021 at 12:49 AM James Lu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Making Bitcoin function after 2038 is by definition a hard fork > >

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-17 Thread vjudeu via bitcoin-dev
> Then starting at Unix Epoch 0x8000, post-softfork nodes just increment > the timestamp by 1 on each new block. It is possible to go even faster. The fastest rate is something like that, if you assume the time in the Genesis Block is zero: 0 1 2 2 3 3 3 3 4 4 4 4 4 4 5 5 5 5 5 5 6 ... The

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-16 Thread ZmnSCPxj via bitcoin-dev
Good morning vjudeu, > > What happens if a series of blocks has a timestamp of 0x at the > > appropriate time? > > The chain will halt for all old clients, because there is no 32-bit value > greater than 0x. > > > 1. Is not violated, since "not lower than" means "greater than or

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-16 Thread Kate Salazar via bitcoin-dev
Hi, BIP 42 is a code base consensus soft fork that at the time of activation does not really manifest as a fork because nobody is running any code not already applying it. Can a similar thing be done in 17 years? (I haven't really made sense of this year 2038 problem, I don't know or understand wha

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-16 Thread David Bakin via bitcoin-dev
yes but ... just for the sake of argument ... if a change such as this wraparound interpretation is made anytime in the next 5 years it'll be over a *decade after that *before any wrapped-around timestamp is legitimately mined ... and by then nobody will be running incompatible (decade old) node so

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-16 Thread vjudeu via bitcoin-dev
> What happens if a series of blocks has a timestamp of 0x at the > appropriate time? The chain will halt for all old clients, because there is no 32-bit value greater than 0x. > 1. Is not violated, since "not lower than" means "greater than or equal to" No, because it has to b

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-15 Thread ZmnSCPxj via bitcoin-dev
Good morning yanmaani, > It's well-known. Nobody really cares, because it's so far off. Not > possible to do by softfork, no. I think it is possible by softfork if we try hard enough? > 1. The block timestamp may not be lower than the median of the last 11 > blocks' > > 2. The block time

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-15 Thread vjudeu via bitcoin-dev
Your solution seems to solve the problem of chain halting, but there are more issues. For example: if you have some time modulo 2^32, then you no longer know if timestamp zero is related to 1970 or 2106 or some higher year. Your "k" value representing in fact the most significant 32 bits of 64-b

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-15 Thread yanmaani--- via bitcoin-dev
It's well-known. Nobody really cares, because it's so far off. Not possible to do by softfork, no. It is possible to do by something that becomes a hardfork in 80 years, though, which is probably good enough. I proposed a solution, but nobody was really interested. Let's see if anyone bites no

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-15 Thread James Lu via bitcoin-dev
Making Bitcoin function after 2038 is by definition a hard fork I feel if we do HF, we should bundle other HF changes with it... On Wed, Oct 13, 2021 at 5:19 PM vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It seems that Bitcoin Core will stop working in 2038 because o

[bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-13 Thread vjudeu via bitcoin-dev
It seems that Bitcoin Core will stop working in 2038 because of assertion checking if the current time is non-negative. Also, the whole chain will halt after reaching median time 0x in 2106. More information: https://bitcointalk.org/index.php?topic=5365359.0 I wonder if that kind of issu