Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 55BE5C000D for ; 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 ; 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 ; 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 ; Sat, 16 Oct 2021 20:37:39 +0000 (UTC) Received: by mail-yb1-xb32.google.com with SMTP id q189so650149ybq.1 for ; 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: <143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet> In-Reply-To: <143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet> From: David Bakin Date: Sat, 16 Oct 2021 13:37:27 -0700 Message-ID: To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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 inc= ompatible (decade old) node software (especially since it would mean that a= decade had gone by without a single=C2=A0consensus=C2=A0change ... = seems very unlikely).

On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-de= v <bitcoin-dev@= lists.linuxfoundation.org> wrote:
> What happens if a series of blocks has a time= stamp 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
--0000000000005a430a05ce7e48ba--