From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 57DE4C000D for ; Fri, 15 Oct 2021 22:27:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3A7CA83AC3 for ; Fri, 15 Oct 2021 22:27:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS4fbNp9m275 for ; Fri, 15 Oct 2021 22:27:12 +0000 (UTC) X-Greylist: delayed 00:05:02 by SQLgrey-1.8.0 Received: from o250.poczta.onet.pl (o250.poczta.onet.pl [213.180.142.250]) by smtp1.osuosl.org (Postfix) with ESMTPS id A04F683A99 for ; Fri, 15 Oct 2021 22:27:11 +0000 (UTC) Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4HWLNS4jTdz1bJj; Sat, 16 Oct 2021 00:22:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1634336520; bh=N/P2Vykp/1HLXvqchC/3b5UrA4bqHDgR2p6T4JvI5Dg=; h=From:To:In-Reply-To:Date:Subject:From; b=oIleQC921sDelsoWC/y9SDIeBYe1DBDlIcsgzKppWtmQGCQD2kSQ7SSF2YjPS3P7a QNArL14iIOx92AiZvdhBE1zZNMweRYjd1akLhZ8l4xOqU2qcdiVUycOGrpkgbpzQ6m qYXGPfyBaVmPgOZvCeyz+L/m6c2G3K/tD8JUao5c= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.13.16] by pmq5v.m5r2.onet via HTTP id ; Sat, 16 Oct 2021 00:22:00 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: yanmaani@cock.li, Bitcoin Protocol Discussion In-Reply-To: <5978620b3db064897840b6170eed25d2@cock.li> Date: Sat, 16 Oct 2021 00:22:00 +0200 Message-Id: <143289360-eb35e705fded3eb4175a6f8d7669b3a0@pmq5v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.13.16;PL;2 X-Mailman-Approved-At: Fri, 15 Oct 2021 22:48:22 +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: Fri, 15 Oct 2021 22:27:13 -0000 Your solution seems to solve the problem of chain halting, but there are mo= re issues. For example: if you have some time modulo 2^32, then you no long= er know if timestamp zero is related to 1970 or 2106 or some higher year. Y= our "k" value representing in fact the most significant 32 bits of 64-bit t= imestamp has to be stored in all cases where time is used. If there is no "= k", then zero should be used for backward compatibility. Skipping "k" could= cause problems related to OP_CHECKLOCKTIMEVERIFY or nLockTime, because if = some transaction was timestamped to 0xbadc0ded, then that transaction will = be valid in 0x00000000badc0ded, invalid in 0x0000000100000000, and valid ag= ain in 0x00000001badc0ded, the same for timelocked outputs. So, I think your "k" value should be added to the coinbase transaction, the= n you can combine two 32-bit values, the lower bits from the block header a= nd the higher bits from the coinbase transaction. Also, adding your "k" val= ue transaction nLockTime field is needed (maybe in a similar way as transac= tion witness was added in Segwit), because in other case after reaching 0x0= 000000100000000 all off-chain transactions with timelocks around 0x00000000= ffffffff will be additionally timelocked for the next N years. The same is = needed for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before t= he currently used value will solve that (and assuming zero if there is only= some 32-bit value). On 2021-10-15 23:48:59 user yanmaani@cock.li wrote: > It's well-known. Nobody really cares, because it's so far off. Not = possible to do by softfork, no. It is possible to do by something that = becomes a hardfork in 80 years, though, which is probably good enough. I proposed a solution, but nobody was really interested. Let's see if = anyone bites now. --- Subject: Suggestion: Solve year 2106 problem by taking timestamps mod = 2^32 To Bitcoin Protocol Discussion Date 2020-09-19 12:36 Message Body Currently, Bitcoin's timestamp rules are as follows: 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) Thus, Bitcoin will "die" on or about 2106-02-07, when there is no = timestamp below 2^32 that exceeds the median of the last 11 blocks. If the rules were changed to the following, this problem would be = solved: 1. The block timestamp plus k*2^32 may not be lower than the median of = the last 11 blocks' 2. The block timestamp plus k*2^32 may not be greater than the current = time plus two hours 3. k is an integer, whose value must be the same for the calculations of = Rule 1 and Rule 2 This would cause a hardfork in the year 2106, which is approximately = 85.5 years from now, by which time 95% of nodes would hopefully have = updated. Another proposed solution is 64-bit timestamps. They would break = compatibility with other software that has specific expectations of = header fields, like ASICs' firmware. They would also cause a hardfork = before the date of timestamp overflow. I thus believe them to be a less = appropriate solution. What do you think of this idea? Is it worth a BIP? On 2021-10-13 19:16, vjudeu via bitcoin-dev wrote: > It seems that Bitcoin Core will stop working in 2038 because of > assertion checking if the current time is non-negative. Also, the > whole chain will halt after reaching median time 0xffffffff in 2106. > More information: https://bitcointalk.org/index.php?topic=3D5365359.0 > = > I wonder if that kind of issues are possible to fix in a soft-fork > way. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev