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