Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 88B13C000D for ; Sat, 16 Oct 2021 21:34:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 71CCC4034A for ; Sat, 16 Oct 2021 21:34:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2kaNR35_5Ez for ; Sat, 16 Oct 2021 21:34:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by smtp4.osuosl.org (Postfix) with ESMTPS id 09D4340342 for ; Sat, 16 Oct 2021 21:34:44 +0000 (UTC) Received: by mail-yb1-xb2d.google.com with SMTP id v195so235528ybb.0 for ; Sat, 16 Oct 2021 14:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=587IPSUIIKx+yi7Vv3+yEZu3wrX0MBKGlKvSKaE8Wck=; b=pSWQy6HbKmmzrj7ef29qClvcjXjwyPkP/kSvtTyywxQgmcoS8+KjMIk4EclFhjjA7m suj/K8Viv4ip990j9PebJEGlFApm3OZY/U1T+0G7Mn/26eZhiP0kA3CSA3wXbyWsHuA5 mKhne8w1ulnohBZTBapk4JZJf9CPTuQp+TB0VlgvKCCTXAgSYszzNiLMZ0B+0dOtxyQV 24tgpG6cVrKLxjx1HmrVg3csDrzTitoYGki9EClfRznvJRK3frCSACAMcJeyT2Ayp589 43M+8SMTpwC1GCpxNzhz7uxXOnbUEPto8v9vdN777St3lRpQfUUpg1gmmmY/AnPMSXA8 sNuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=587IPSUIIKx+yi7Vv3+yEZu3wrX0MBKGlKvSKaE8Wck=; b=5nBeTFJvto0FTvBQ/GACYFyLikHrDiD6yoPYg5lIe8Fm8SEYcZU991UCiwPzJovDQn pS6OC+leqrp+pkByfI8f4hODiqmuwJ0OJbHBQHAmN9Oa3wictxTSDhCppPHFAWamorow FJForYCE49AkdvtzXdJjOdQTINoArpf6wABgER9ZnDcmcN5eZoyizx5FLgXCc8cZH6A5 e+kdWfPaL7yQq6qQblaY7NSXnj5LzJynBCAM+Vqrlb5EwssZ7V4AXbQFBRIf+ZMMtekQ Yebh84z7PffSpkaH+I6bMUM287vOjY0VJCQ/cwr0yVzowF73w6GagmfL1c4gfT8nR6gZ 3V3A== X-Gm-Message-State: AOAM530Lh6pvyauGkr4wf8yaLyvwsnj8TJUJNoId6i+mn6AymNJNVSGz DBQylOsPNBzbiNQdQoExyyXarI4kN+v7ghsjRU2Ym2/EiImP15lH X-Google-Smtp-Source: ABdhPJzIo69vhyoEd5PyqlynrCR6S8RpVwfrhz9zbTze6rh4ZrqX9rVm3RNicx9Q81vMVxd9pnivMtzCGBz/pkBe+ng= X-Received: by 2002:a25:ae92:: with SMTP id b18mr21121503ybj.220.1634420083931; Sat, 16 Oct 2021 14:34:43 -0700 (PDT) MIME-Version: 1.0 References: <143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet> In-Reply-To: From: Kate Salazar Date: Sat, 16 Oct 2021 23:34:32 +0200 Message-ID: To: David Bakin , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000843ca505ce7f142a" X-Mailman-Approved-At: Sat, 16 Oct 2021 21:48:57 +0000 Subject: Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2021 21:34:46 -0000 --000000000000843ca505ce7f142a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ov= er > a *decade after that *before any wrapped-around timestamp is legitimately > mined ... and by then nobody will be running incompatible (decade old) no= de > software (especially since it would mean that a decade had gone by withou= t > 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 th= e >> appropriate time? >> >> The chain will halt for all old clients, because there is no 32-bit valu= e >> greater than 0xffffffff. >> >> > 1. Is not violated, since "not lower than" means "greater than or equa= l >> 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/6f0cbc75be7644c276650fd98bfdb635= 8b827399/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 violate= d >> 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 block= s >> is no longer possible. The only soft-fork solution I can see require >> overwriting that block. >> >> Example from https://bitcointalk.org/index.php?topic=3D5365359.0 >> >> submitblock >> 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f= 3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0ffffffffffff= f7f200100000001020000000001010000000000000000000000000000000000000000000000= 000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b= 15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f= 71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000= 000000000000000000000000000000000000000000000000000000000 >> null >> generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt >> CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestam= p >> 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 1= 1 >> > 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 =3D= =3D >> 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 coinb= ase >> 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 v= 1 >> 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 > --000000000000843ca505ce7f142a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 run= ning any code not already applying it. Can a similar thing be done in 17 ye= ars? (I haven't really made sense of this year 2038 problem, I don'= t know or understand what is required=C2=A0if there's something to be d= one).
Cheers!

On Sat, Oct 16, 2021 at 11:00 PM David Bakin via bit= coin-dev <bitco= in-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= =C2=A0before any wrapped-around timestamp is legitimately mined ... and= by then nobody will be running incompatible (decade old) node software (es= pecially since it would mean that a decade had gone by without a single<= /i>=C2=A0consensus=C2=A0change ... seems very unlikely).

On Sat, Oct 16, 202= 1 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 g= reater than 0xffffffff.

> 1. Is not violated, since "not lower than" means "great= er than or equal to"

No, because it has to be strictly "greater than" in the Bitcoin C= ore source code, it is rejected when it is "lower or equal to", s= ee: https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c27665= 0fd98bfdb6358b827399/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 poi= nt to some time around 1970, so for old clients two rules are violated at t= he same time.

> 3. Is not violated since 0xFFFFFFFF < 0x100000000.

This is hard to change, because 32-bit timestamps are included in block hea= ders, 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 ha= lting 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, m= edian time is equal to 0xffffffff and adding any new blocks is no longer po= ssible. The only soft-fork solution I can see require overwriting that bloc= k.

Example from https://bitcointalk.org/index.php?to= pic=3D5365359.0

submitblock 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73= cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fff= ffffffffff7f200100000001020000000001010000000000000000000000000000000000000= 000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a9= 1462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9e= de2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000= 000000000000000000000000000000000000000000000000000000000000000000
null
generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
CreateNewBlock: TestBlockValidity failed: time-too-old, block's timesta= mp is too early (code -1)

I don't know any timestamp that can be used in any next block and accep= ted 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.=C2=A0 The block timestamp may not be lower than the median of the l= ast 11
>=C2=A0 =C2=A0 =C2=A0blocks'
>
> 2.=C2=A0 The block timestamp may not be greater than the current time = plus two
>=C2=A0 =C2=A0 =C2=A0hours
>
> 3.=C2=A0 The block timestamp may not be greater than 2^32 (Sun, 07 Feb= 2106
>=C2=A0 =C2=A0 =C2=A006:28:16 +0000)

What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the app= ropriate time?

In that case:

1.=C2=A0 Is not violated, since "not lower than" means "grea= ter than or equal to", and after a while the median becomes 0xFFFFFFFF= and 0xFFFFFFFF =3D=3D 0xFFFFFFFF
2.=C2=A0 Is not violated, since it would be a past actual real time.
3.=C2=A0 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 transa= ction, 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 t= he 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/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000843ca505ce7f142a--