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 9DF21C000D for ; Sun, 12 Sep 2021 19:39:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 7AF1F605F5 for ; Sun, 12 Sep 2021 19:39:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl 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 pbFKEL_k8-Ir for ; Sun, 12 Sep 2021 19:38:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo105.poczta.onet.pl (smtpo105.poczta.onet.pl [213.180.149.158]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1B4EF605E4 for ; Sun, 12 Sep 2021 19:38:57 +0000 (UTC) Received: from pmq4v.m5r2.onet (pmq4v.m5r2.onet [10.174.32.70]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4H70KQ2hTGz1rPs; Sun, 12 Sep 2021 21:38:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1631475530; bh=HzT7zMScANcPVpC9pB1m2P8r72OVeljtwGyYxIgftN0=; h=From:To:In-Reply-To:Date:Subject:From; b=mIsGQbtz75xhys9QhVSkSs8CBrdlHIBDPQdeBCOVQBhoZ7D2qSnes4Y18wAoEEnhJ zYtMJJn60tuXZALo91ARBI0uCPxEG0mWegXj8Ttfn4eM9ZqiuOQlgxvS8flSLDuebA BX/xCGV+FgD2lFtW6sYE91J+dIxihuoVz/imySXw= Content-Type: multipart/alternative; boundary="===============7376952736231412599==" MIME-Version: 1.0 Received: from [5.173.253.144] by pmq4v.m5r2.onet via HTTP id ; Sun, 12 Sep 2021 21:38:50 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: James Lu ,bitcoin-dev@lists.linuxfoundation.org In-Reply-To: Date: Sun, 12 Sep 2021 21:38:47 +0200 Message-Id: <140815317-3f36d45615e153403b3c83e26c266773@pmq4v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.253.144;PL;2 X-Mailman-Approved-At: Sun, 12 Sep 2021 19:49:23 +0000 Subject: Re: [bitcoin-dev] Proposal: Auto-shutdown as 5-year fork window 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: Sun, 12 Sep 2021 19:39:00 -0000 This is a multi-part message in MIME format. --===============7376952736231412599== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You can do that kind of change in your own Bitcoin-compatible client, but y= ou cannot be sure that other people will run that version and that it will = shut down when you want. Many miners use their own custom software for mini= ng blocks, the same for mining pools. There are many clients that are compa= tible with consensus, but different than Bitcoin Core. Also you should notice that Bitcoin community make changes by using soft-fo= rks, not hard-forks. Backward compatibility is preserved as often as possib= le and there is no reason to change that. Any change can be deployed in a s= oft-fork way, even "evil soft-forks" are possible, as described in https://= petertodd.org/2016/forced-soft-forks. I think that kind of soft-fork is sti= ll better than hard-fork. On 2021-09-12 21:16:00 user James Lu via bitcoin-dev wrote: If MTP-11 is greater than 5 years after the release date of the current sof= tware version, the full node should shut down automatically. =C2=A0 This would=C2=A0allow writing code that=C2=A0gives the community ~5 years t= o upgrade to a version that executes a new hard fork while keeping everyone= in consensus, provided the change is non-controversial. --===============7376952736231412599== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
You can do that kind of change in your own Bitcoin-compatible client, = but you cannot be sure that other people will run that version and that it = will shut down when you want. Many miners use their own custom software for= mining blocks, the same for mining pools. There are many clients that are = compatible with consensus, but different than Bitcoin Core.

Also= you should notice that Bitcoin community make changes by using soft-forks,= not hard-forks. Backward compatibility is preserved as often as possible a= nd there is no reason to change that. Any change can be deployed in a soft-= fork way, even "evil soft-forks" are possible, as described in https://pete= rtodd.org/2016/forced-soft-forks. I think that kind of soft-fork is still b= etter than hard-fork.

On 2021-09-12 21:16:00 user James Lu via bitcoin-dev <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
If MTP-11 is greater than 5 years af= ter the release date of the current software version, the full node should = shut down automatically.
 
This would allow writing code t= hat gives the community ~5 years to upgrade to a version that executes= a new hard fork while keeping everyone in consensus, provided the change i= s non-controversial.
--===============7376952736231412599==--