path: root/14/5d8690b474d7751752c773ebd2051ea7446bb7

Return-Path: <david@bakins-bits.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 55BE5C000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 20:37:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 322DB6069D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 20:37:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=bakins-bits-com.20210112.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id c_UD74IfOgOT
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 20:37:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com
 [IPv6:2607:f8b0:4864:20::b32])
 by smtp3.osuosl.org (Postfix) with ESMTPS id BD08B60613
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 20:37:39 +0000 (UTC)
Received: by mail-yb1-xb32.google.com with SMTP id q189so650149ybq.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 13:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bakins-bits-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=ozzibHSBRRPJL1bfYyNMmUZBxPhuuwmYkIJluYph36k=;
 b=p7WAIw+yO1k2fd0ACr8kqh1GsCkIhDRSeFd6yRV/fdAf3M/T8jaGRH0TCqUo8bIraw
 ZsfKA9cT9WPG6yc7tZUojiTPBJlsFqGx8yAaetIKX4VjyH9JJJ06HzXlMsRnD2waE37h
 HEI+S7DY7hkPWo8NMX8Rd7RGPVbP4/rVLftRkP825YiVsmvR0W75tnG85bZ0WZW7KS5L
 x+pVwAsK/SHiP8jECZ+LJfdqclcNsd1aepnSSWbqsZveDwID11BpRslKX1LaXQruGxc5
 SwRxdg7ReXjqbzSWjsIQGkikjhAoNrsv7BHnE6QJsU71BymOJ46lEJvE6P8KLXgvYYVC
 JnxQ==
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;
 bh=ozzibHSBRRPJL1bfYyNMmUZBxPhuuwmYkIJluYph36k=;
 b=TtueyyFxfj4yuDz5ukHpw4dTgV6LgCSncTanzWEo4BL5mGnhLvbhJxZueS8Rm/p5tb
 pSFtnHlyJaVRruoKXwTccYaQMY5DkSN29s1CUtS8MfbsxC449vq/a6xT2nHTI7d+oOtx
 8EnnrCq2F+xM3t8NnpQ0hlFw4ODHy4d92iHp+sn7Ls91zbl9J8c5TcvUlqXpeoliDphl
 KQNUo3QzXhSveo7BHZU0xKX3T3u0yOXdTzrgWAz+PN+x8LI6qVGyDCPzjEwzF1vOcTnD
 lfVikbPsiraZgwPtdyI1aLtcVoFCFvsdqm0JRVPQWFAMjFjfXhLMwLMfTreOonP9kCVt
 B9Yg==
X-Gm-Message-State: AOAM533vHt0qAKeXqIoQuv1jobSi7rt1QjSPTOorXPEaThSWU5qeq39l
 8Mmisd9UHpkNFs8da3SxOkFdd+rVQ32mM9W1SAQgJj3ohk0=
X-Google-Smtp-Source: ABdhPJzWAaAvQ3uIqODxgYfuLryqd51iQ84oVGb9lUyZtUDxlrKcWlDMv/32Xt9hwQ4yCK1eCbcsYFkagv8AUuhZNqw=
X-Received: by 2002:a5b:110:: with SMTP id 16mr20862570ybx.392.1634416658623; 
 Sat, 16 Oct 2021 13:37:38 -0700 (PDT)
MIME-Version: 1.0
References: <nSiUl71p9JyISxvRJ3Jq71zNahe-rpanbFFv1MSHSk7rUKjq36yD7vmrJQ5Pnh5oUdDAFflgSzbCE5KK7RacFRepvjqFc9xp9qT7hU-twXA=@protonmail.com>
 <143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet>
In-Reply-To: <143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet>
From: David Bakin <david@bakins-bits.com>
Date: Sat, 16 Oct 2021 13:37:27 -0700
Message-ID: <CAF-gu8h0BJOnHUjdjLPh4_pQ0j1Xxuwb5axQnNetk_ctTNo-4Q@mail.gmail.com>
To: vjudeu@gazeta.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005a430a05ce7e48ba"
X-Mailman-Approved-At: Sat, 16 Oct 2021 20:59:47 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Oct 2021 20:37:41 -0000

--0000000000005a430a05ce7e48ba
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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/6f0cbc75be7644c276650fd98bfdb6358=
b827399/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=3D5365359.0
>
> submitblock
> 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3=
663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff=
7f2001000000010200000000010100000000000000000000000000000000000000000000000=
00000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b1=
5cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f7=
1d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf901200000000000000000=
00000000000000000000000000000000000000000000000000000000
> 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 accepte=
d
> 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 t=
wo
> >     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-bi=
t
> (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-b=
it.
>
> 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
>

--0000000000005a430a05ce7e48ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">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&#39;ll be over a <i>decade after that=C2=A0</i>before any wrapped-around=
 timestamp is legitimately mined ... and by then nobody will be running inc=
ompatible (decade old) node software (especially since it would mean that a=
 decade had gone by without a <i>single</i>=C2=A0consensus=C2=A0change ... =
seems very unlikely).</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">&gt; What happens if a series of blocks has a time=
stamp of 0xFFFFFFFF at the appropriate time?<br>
<br>
The chain will halt for all old clients, because there is no 32-bit value g=
reater than 0xffffffff.<br>
<br>
&gt; 1. Is not violated, since &quot;not lower than&quot; means &quot;great=
er than or equal to&quot;<br>
<br>
No, because it has to be strictly &quot;greater than&quot; in the Bitcoin C=
ore source code, it is rejected when it is &quot;lower or equal to&quot;, s=
ee: <a href=3D"https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c27665=
0fd98bfdb6358b827399/src/validation.cpp#L3089-L3094" rel=3D"noreferrer" tar=
get=3D"_blank">https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c27665=
0fd98bfdb6358b827399/src/validation.cpp#L3089-L3094</a><br>
<br>
&gt; 2. Is not violated, since it would be a past actual real time.<br>
<br>
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.<br>
<br>
&gt; 3. Is not violated since 0xFFFFFFFF &lt; 0x100000000.<br>
<br>
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&#39;s why I think new timestamps should be=
 placed in the coinbase transaction. But that still does not solve chain ha=
lting problem.<br>
<br>
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.<br>
<br>
Example from <a href=3D"https://bitcointalk.org/index.php?topic=3D5365359.0=
" rel=3D"noreferrer" target=3D"_blank">https://bitcointalk.org/index.php?to=
pic=3D5365359.0</a><br>
<br>
submitblock 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73=
cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fff=
ffffffffff7f200100000001020000000001010000000000000000000000000000000000000=
000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a9=
1462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9e=
de2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000=
000000000000000000000000000000000000000000000000000000000000000000<br>
null<br>
generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt<br>
CreateNewBlock: TestBlockValidity failed: time-too-old, block&#39;s timesta=
mp is too early (code -1)<br>
<br>
I don&#39;t know any timestamp that can be used in any next block and accep=
ted by old nodes.<br>
<br>
On 2021-10-16 01:01:54 user ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonm=
ail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br>
&gt; Good morning yanmaani,<br>
<br>
<br>
&gt; It&#39;s well-known. Nobody really cares, because it&#39;s so far off.=
 Not<br>
&gt; possible to do by softfork, no.<br>
<br>
I think it is possible by softfork if we try hard enough?<br>
<br>
<br>
&gt; 1.=C2=A0 The block timestamp may not be lower than the median of the l=
ast 11<br>
&gt;=C2=A0 =C2=A0 =C2=A0blocks&#39;<br>
&gt;<br>
&gt; 2.=C2=A0 The block timestamp may not be greater than the current time =
plus two<br>
&gt;=C2=A0 =C2=A0 =C2=A0hours<br>
&gt;<br>
&gt; 3.=C2=A0 The block timestamp may not be greater than 2^32 (Sun, 07 Feb=
 2106<br>
&gt;=C2=A0 =C2=A0 =C2=A006:28:16 +0000)<br>
<br>
What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the app=
ropriate time?<br>
<br>
In that case:<br>
<br>
1.=C2=A0 Is not violated, since &quot;not lower than&quot; means &quot;grea=
ter than or equal to&quot;, and after a while the median becomes 0xFFFFFFFF=
 and 0xFFFFFFFF =3D=3D 0xFFFFFFFF<br>
2.=C2=A0 Is not violated, since it would be a past actual real time.<br>
3.=C2=A0 Is not violated since 0xFFFFFFFF &lt; 0x100000000.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005a430a05ce7e48ba--