Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 a hardfork either way. The important bit here is "as long as it doesn't change anything now" - this is indeed a hardfork, but it's a timestamp-activated hardfork that triggers in 2106. Until that point, it has absolutely no bearing on consensus rules (as opposed to the other proposals, which are at least a soft-fork today). I understand that there's some problems in getting consensus for forks, but surely we can agree that everyone will update their Bitcoin at least once in the next 85 years? (If they don't, they're doomed anyway.) On 2021-10-17 15:46, Kate Salazar wrote: Hi yanmaani ... This is a hardfork, yes, but it's a hardfork that kicks in way into the future. And because it's a hardfork, you might as well do anything, as long as it doesn't change anything now. "Anything" is quite a word. Ideally, hard fork requires upgrading every node that can be upgraded, or at least have the node operator's consent to lose the node (for every node that can't be upgraded). ... ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 our benefit. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. On 2021-10-15 08:27, James Lu via bitcoin-dev wrote: 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 wrote: 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 issues are possible to fix in a soft-fork way. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 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 will violate 2 hour rule. Nothing is added to coinbase or > anywhere else. > > It's possible that you'd need some extra logic for locktime, yes, but it > would only be a problem in very special cases. Worst-case, you'll have > to use block time locking in the years around the switch, or softfork in > 64-bit locking. > > But unless I'm missing something, 32-bit would be enough, you just > wouldn't be able to locktime something past the timestamp for the > switch. After the switchover, everything would be back to normal. > > This is a hardfork, yes, but it's a hardfork that kicks in way into the > future. And because it's a hardfork, you might as well do anything, as > long as it doesn't change anything now. > "Anything" is quite a word. Ideally, hard fork requires upgrading every node that can be upgraded, or at least have the node operator's consent to lose the node (for every node that can't be upgraded). > > On 2021-10-15 22:22, vju...@gazeta.pl wrote: > > 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-bit timestamp has to be stored in all cases > > where time is used. If there is no "k", then zero should be used for > > backward compatibility. Skipping "k" could cause problems related to > > OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was > > timestamped to 0xbadc0ded, then that transaction will be valid in > > 0xbadc0ded, invalid in 0x0001, and valid again in > > 0x0001badc0ded, the same for timelocked outputs. > > > > So, I think your "k" value should be added to the coinbase > > transaction, then you can combine two 32-bit values, the lower bits > > from the block header and the higher bits from the coinbase > > transaction. Also, adding your "k" value transaction nLockTime field > > is needed (maybe in a similar way as transaction witness was added in > > Segwit), because in other case after reaching 0x0001 all > > off-chain transactions with timelocks around 0x will > > be additionally timelocked for the next N years. The same is needed > > for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the > > currently used value will solve that (and assuming zero if there is > > only some 32-bit value). > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 will violate 2 hour rule. Nothing is added to coinbase or anywhere else. It's possible that you'd need some extra logic for locktime, yes, but it would only be a problem in very special cases. Worst-case, you'll have to use block time locking in the years around the switch, or softfork in 64-bit locking. But unless I'm missing something, 32-bit would be enough, you just wouldn't be able to locktime something past the timestamp for the switch. After the switchover, everything would be back to normal. This is a hardfork, yes, but it's a hardfork that kicks in way into the future. And because it's a hardfork, you might as well do anything, as long as it doesn't change anything now. On 2021-10-15 22:22, vju...@gazeta.pl wrote: 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-bit timestamp has to be stored in all cases where time is used. If there is no "k", then zero should be used for backward compatibility. Skipping "k" could cause problems related to OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was timestamped to 0xbadc0ded, then that transaction will be valid in 0xbadc0ded, invalid in 0x0001, and valid again in 0x0001badc0ded, the same for timelocked outputs. So, I think your "k" value should be added to the coinbase transaction, then you can combine two 32-bit values, the lower bits from the block header and the higher bits from the coinbase transaction. Also, adding your "k" value transaction nLockTime field is needed (maybe in a similar way as transaction witness was added in Segwit), because in other case after reaching 0x0001 all off-chain transactions with timelocks around 0x will be additionally timelocked for the next N years. The same is needed for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the currently used value will solve that (and assuming zero if there is only some 32-bit value). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 > > 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 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 issues are possible to fix in a soft-fork way. >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
> 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 ... Then you can increment timestamps once per 6 blocks, that means x3600 increase, but then the difficulty is always multiplied by four, so you have to increase time once per difficulty change to keep it on real level, then it will wave between being multiplied by 4 and by 0.25. On 2021-10-17 01:23:24 user ZmnSCPxj wrote: > 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 equal to" > > No, because it has to be strictly "greater than" in the Bitcoin Core source > code, it is rejected when it is "lower or equal to", > see:https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094 Then starting at Unix Epoch 0x8000, post-softfork nodes just increment the timestamp by 1 on each new block. This just kicks the can since that then imposes a limit on the maximum number of blocks, but at least the unit is now ~10 minutes instead of 1 second, a massive x600 increase in the amount of time we are forced to hardfork. On the other hand, this does imply that the difficulty calculation will become astronomically and ludicrously high, since pre-softfork nodes will think that blocks are arriving at the rate of 1 per second, so ... Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 equal to" > > No, because it has to be strictly "greater than" in the Bitcoin Core source > code, it is rejected when it is "lower or equal to", > see:https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094 Then starting at Unix Epoch 0x8000, post-softfork nodes just increment the timestamp by 1 on each new block. This just kicks the can since that then imposes a limit on the maximum number of blocks, but at least the unit is now ~10 minutes instead of 1 second, a massive x600 increase in the amount of time we are forced to hardfork. On the other hand, this does imply that the difficulty calculation will become astronomically and ludicrously high, since pre-softfork nodes will think that blocks are arriving at the rate of 1 per second, so ... Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 what is required if there's something to be done). Cheers! On Sat, Oct 16, 2021 at 11:00 PM David Bakin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > software (especially since it would mean that a decade had gone by without > a *single* consensus change ... seems very unlikely). > > On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > 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 be strictly "greater than" in the Bitcoin Core >> source code, it is rejected when it is "lower or equal to", see: >> https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094 >> >> > 2. Is not violated, since it would be a past actual real time. >> >> If the current time is 0x0001, then the lowest 32 bits will >> point to some time around 1970, so for old clients two rules are violated >> at the same time. >> >> > 3. Is not violated since 0x < 0x1. >> >> This is hard to change, because 32-bit timestamps are included in block >> headers, so using any wider data type here will make it >> hardware-incompatible and will cause a hard-fork. That's why I think new >> timestamps should be placed in the coinbase transaction. But that still >> does not solve chain halting problem. >> >> To test chain halting, all that is needed is starting regtest and >> producing one block with 0x timestamp, just after the Genesis >> Block. Then, median time is equal to 0x and adding any new blocks >> is no longer possible. The only soft-fork solution I can see require >> overwriting that block. >> >> Example from https://bitcointalk.org/index.php?topic=5365359.0 >> >> submitblock >> 010006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0f7f20010001020101035101010200f2052a01001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120 >> null >> generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt >> CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp >> is too early (code -1) >> >> I don't know any timestamp that can be used in any next block and >> accepted by old nodes. >> >> On 2021-10-16 01:01:54 user ZmnSCPxj wrote: >> > 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 timestamp may not be greater than the current time plus >> two >> > hours >> > >> > 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106 >> > 06:28:16 +) >> >> What happens if a series of blocks has a timestamp of 0x at the >> appropriate time? >> >> In that case: >> >> 1. Is not violated, since "not lower than" means "greater than or equal >> to", and after a while the median becomes 0x and 0x == >> 0x >> 2. Is not violated, since it would be a past actual real time. >> 3. Is not violated since 0x < 0x1. >> >> In that case, we could then add an additional rule, which is that a >> 64-bit (or 128-bit, or 256-bit) timestamp has to be present in the coinbase >> transaction, with similar rules except translated to 64-bit/128-bit/256-bit. >> >> Possibly a similar scheme could be used for `nLockTime`; we could put a >> 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1 >> if the legacy v`nLockTime` is at the maximum seconds-timelock possible. >> >> Regards, >> ZmnSCPxj >> >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfo
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 software (especially since it would mean that a decade had gone by without a *single* consensus change ... seems very unlikely). On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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 be strictly "greater than" in the Bitcoin Core > source code, it is rejected when it is "lower or equal to", see: > https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094 > > > 2. Is not violated, since it would be a past actual real time. > > If the current time is 0x0001, then the lowest 32 bits will > point to some time around 1970, so for old clients two rules are violated > at the same time. > > > 3. Is not violated since 0x < 0x1. > > This is hard to change, because 32-bit timestamps are included in block > headers, so using any wider data type here will make it > hardware-incompatible and will cause a hard-fork. That's why I think new > timestamps should be placed in the coinbase transaction. But that still > does not solve chain halting problem. > > To test chain halting, all that is needed is starting regtest and > producing one block with 0x timestamp, just after the Genesis > Block. Then, median time is equal to 0x and adding any new blocks > is no longer possible. The only soft-fork solution I can see require > overwriting that block. > > Example from https://bitcointalk.org/index.php?topic=5365359.0 > > submitblock > 010006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0f7f20010001020101035101010200f2052a01001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120 > null > generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt > CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp > is too early (code -1) > > I don't know any timestamp that can be used in any next block and accepted > by old nodes. > > On 2021-10-16 01:01:54 user ZmnSCPxj wrote: > > 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 timestamp may not be greater than the current time plus two > > hours > > > > 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106 > > 06:28:16 +) > > What happens if a series of blocks has a timestamp of 0x at the > appropriate time? > > In that case: > > 1. Is not violated, since "not lower than" means "greater than or equal > to", and after a while the median becomes 0x and 0x == > 0x > 2. Is not violated, since it would be a past actual real time. > 3. Is not violated since 0x < 0x1. > > In that case, we could then add an additional rule, which is that a 64-bit > (or 128-bit, or 256-bit) timestamp has to be present in the coinbase > transaction, with similar rules except translated to 64-bit/128-bit/256-bit. > > Possibly a similar scheme could be used for `nLockTime`; we could put a > 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1 > if the legacy v`nLockTime` is at the maximum seconds-timelock possible. > > Regards, > ZmnSCPxj > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
> 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 be strictly "greater than" in the Bitcoin Core source code, it is rejected when it is "lower or equal to", see: https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094 > 2. Is not violated, since it would be a past actual real time. If the current time is 0x0001, then the lowest 32 bits will point to some time around 1970, so for old clients two rules are violated at the same time. > 3. Is not violated since 0x < 0x1. This is hard to change, because 32-bit timestamps are included in block headers, so using any wider data type here will make it hardware-incompatible and will cause a hard-fork. That's why I think new timestamps should be placed in the coinbase transaction. But that still does not solve chain halting problem. To test chain halting, all that is needed is starting regtest and producing one block with 0x timestamp, just after the Genesis Block. Then, median time is equal to 0x and adding any new blocks is no longer possible. The only soft-fork solution I can see require overwriting that block. Example from https://bitcointalk.org/index.php?topic=5365359.0 submitblock 010006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0f7f20010001020101035101010200f2052a01001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120 null generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp is too early (code -1) I don't know any timestamp that can be used in any next block and accepted by old nodes. On 2021-10-16 01:01:54 user ZmnSCPxj wrote: > 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 timestamp may not be greater than the current time plus two > hours > > 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106 > 06:28:16 +) What happens if a series of blocks has a timestamp of 0x at the appropriate time? In that case: 1. Is not violated, since "not lower than" means "greater than or equal to", and after a while the median becomes 0x and 0x == 0x 2. Is not violated, since it would be a past actual real time. 3. Is not violated since 0x < 0x1. In that case, we could then add an additional rule, which is that a 64-bit (or 128-bit, or 256-bit) timestamp has to be present in the coinbase transaction, with similar rules except translated to 64-bit/128-bit/256-bit. Possibly a similar scheme could be used for `nLockTime`; we could put a 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1 if the legacy v`nLockTime` is at the maximum seconds-timelock possible. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 timestamp may not be greater than the current time plus two > hours > > 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106 > 06:28:16 +) What happens if a series of blocks has a timestamp of 0x at the appropriate time? In that case: 1. Is not violated, since "not lower than" means "greater than or equal to", and after a while the median becomes 0x and 0x == 0x 2. Is not violated, since it would be a past actual real time. 3. Is not violated since 0x < 0x1. In that case, we could then add an additional rule, which is that a 64-bit (or 128-bit, or 256-bit) timestamp has to be present in the coinbase transaction, with similar rules except translated to 64-bit/128-bit/256-bit. Possibly a similar scheme could be used for `nLockTime`; we could put a 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1 if the legacy v`nLockTime` is at the maximum seconds-timelock possible. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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-bit timestamp has to be stored in all cases where time is used. If there is no "k", then zero should be used for backward compatibility. Skipping "k" could cause problems related to OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was timestamped to 0xbadc0ded, then that transaction will be valid in 0xbadc0ded, invalid in 0x0001, and valid again in 0x0001badc0ded, the same for timelocked outputs. So, I think your "k" value should be added to the coinbase transaction, then you can combine two 32-bit values, the lower bits from the block header and the higher bits from the coinbase transaction. Also, adding your "k" value transaction nLockTime field is needed (maybe in a similar way as transaction witness was added in Segwit), because in other case after reaching 0x0001 all off-chain transactions with timelocks around 0x will be additionally timelocked for the next N years. The same is needed for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the currently used value will solve that (and assuming zero if there is only some 32-bit value). On 2021-10-15 23:48:59 user yanma...@cock.li wrote: > 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 now. --- Subject: Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 To Bitcoin Protocol Discussion Date2020-09-19 12:36 Message Body Currently, Bitcoin's timestamp rules are as follows: 1. The block timestamp may not be lower than the median of the last 11 blocks' 2. The block timestamp may not be greater than the current time plus two hours 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106 06:28:16 +) Thus, Bitcoin will "die" on or about 2106-02-07, when there is no timestamp below 2^32 that exceeds the median of the last 11 blocks. If the rules were changed to the following, this problem would be solved: 1. The block timestamp plus k*2^32 may not be lower than the median of the last 11 blocks' 2. The block timestamp plus k*2^32 may not be greater than the current time plus two hours 3. k is an integer, whose value must be the same for the calculations of Rule 1 and Rule 2 This would cause a hardfork in the year 2106, which is approximately 85.5 years from now, by which time 95% of nodes would hopefully have updated. Another proposed solution is 64-bit timestamps. They would break compatibility with other software that has specific expectations of header fields, like ASICs' firmware. They would also cause a hardfork before the date of timestamp overflow. I thus believe them to be a less appropriate solution. What do you think of this idea? Is it worth a BIP? On 2021-10-13 19:16, vjudeu via bitcoin-dev wrote: > 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 issues are possible to fix in a soft-fork > way. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 now. --- Subject: Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 To Bitcoin Protocol Discussion Date2020-09-19 12:36 Message Body Currently, Bitcoin's timestamp rules are as follows: 1. The block timestamp may not be lower than the median of the last 11 blocks' 2. The block timestamp may not be greater than the current time plus two hours 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106 06:28:16 +) Thus, Bitcoin will "die" on or about 2106-02-07, when there is no timestamp below 2^32 that exceeds the median of the last 11 blocks. If the rules were changed to the following, this problem would be solved: 1. The block timestamp plus k*2^32 may not be lower than the median of the last 11 blocks' 2. The block timestamp plus k*2^32 may not be greater than the current time plus two hours 3. k is an integer, whose value must be the same for the calculations of Rule 1 and Rule 2 This would cause a hardfork in the year 2106, which is approximately 85.5 years from now, by which time 95% of nodes would hopefully have updated. Another proposed solution is 64-bit timestamps. They would break compatibility with other software that has specific expectations of header fields, like ASICs' firmware. They would also cause a hardfork before the date of timestamp overflow. I thus believe them to be a less appropriate solution. What do you think of this idea? Is it worth a BIP? On 2021-10-13 19:16, vjudeu via bitcoin-dev wrote: 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 issues are possible to fix in a soft-fork way. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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 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 issues are possible to fix in a soft-fork way. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
