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

[David Bakin <david@bakins-bits.com>]

[-- Attachment #1: Type: text/plain, Size: 4592 bytes --]

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 0xFFFFFFFF at the
> appropriate time?
>
> The chain will halt for all old clients, because there is no 32-bit value
> greater than 0xffffffff.
>
> > 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 0x0000000100000000, 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 0xFFFFFFFF < 0x100000000.
>
> 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 0xffffffff timestamp, just after the Genesis
> Block. Then, median time is equal to 0xffffffff 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
> 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff7f200100000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
> 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 <ZmnSCPxj@protonmail.com> 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 +0000)
>
> What happens if a series of blocks has a timestamp of 0xFFFFFFFF 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 0xFFFFFFFF and 0xFFFFFFFF ==
> 0xFFFFFFFF
> 2.  Is not violated, since it would be a past actual real time.
> 3.  Is not violated since 0xFFFFFFFF < 0x100000000.
>
> 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
>

[-- Attachment #2: Type: text/html, Size: 5632 bytes --]