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