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 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 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >