From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C24F6C000D for ; Fri, 15 Oct 2021 15:54:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A48D760AF6 for ; Fri, 15 Oct 2021 15:54:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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=cock.li 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 qLB7k3hooEHC for ; Fri, 15 Oct 2021 15:54:13 +0000 (UTC) X-Greylist: delayed 00:09:08 by SQLgrey-1.8.0 Received: from mail.cock.li (mail.cock.li [37.120.193.124]) by smtp3.osuosl.org (Postfix) with ESMTPS id 8D6D16077A for ; Fri, 15 Oct 2021 15:54:13 +0000 (UTC) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail; t=1634312699; bh=5cuwctddvU0FObOPLfxbDCZH0XwxqM4aIl8Lp8ibFNc=; h=Date:From:To:Subject:In-Reply-To:References:From; b=VqGI0hvSIt2S2j3aNqg4jJ3LM/e9Apw75ZUjSr5AOor1Gya5moOt1VIfXHVhFTUWQ P5s0BLSLI9gcai3HQAJERl8C0XZDfD5XwaX/20W+gbnqc3T9qeXTvXcYJddJv7QX3G 2Z9cCRV/6vXil+/VIO43TcCIHlQpgiOzTxhKz7N32pLq/3LK5v2LdpvIbxLrzwv+Si WnhBceZBybTGiG04yy5HvHTrY+OTTln+OBaNKKjDqZP9hf/fcfrhT8ipK2TbSYZoGK 91fCbYr4TlcrOPs95hCXUaRVU+h3WgeZ5y9NmPmtO3O3bpRUjCNyVcYzuHBAs/PDpf Fb7t2MreZNU9Q== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 15 Oct 2021 15:44:59 +0000 From: yanmaani@cock.li To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion In-Reply-To: <50769965-423dd279413d4dba11ba459cbd98387b@pmq6v.m5r2.onet> References: <50769965-423dd279413d4dba11ba459cbd98387b@pmq6v.m5r2.onet> Message-ID: <5978620b3db064897840b6170eed25d2@cock.li> X-Sender: yanmaani@cock.li User-Agent: Roundcube Webmail/1.3.16 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 15:54:19 -0000 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=5365359.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