From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id C1DDAC007A for ; Fri, 22 Apr 2022 00:28:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 908F241C4A for ; Fri, 22 Apr 2022 00:28:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvmW6MY26sjm for ; Fri, 22 Apr 2022 00:28:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp4.osuosl.org (Postfix) with ESMTPS id 2BC8E41B2E for ; Fri, 22 Apr 2022 00:28:49 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1nhhAC-0004w6-Sz; Fri, 22 Apr 2022 10:28:46 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 22 Apr 2022 10:28:40 +1000 Date: Fri, 22 Apr 2022 10:28:40 +1000 From: Anthony Towns To: "David A. Harding" , Bitcoin Protocol Discussion Message-ID: <20220422002840.GB5616@erisian.com.au> References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -13 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV 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, 22 Apr 2022 00:28:51 -0000 On Wed, Apr 20, 2022 at 03:04:53PM -1000, David A. Harding via bitcoin-dev wrote: > The main criticisms I'm aware of against CTV seem to be along the following > lines: [...] > Could those concerns be mitigated by making CTV an automatically reverting > consensus change with an option to renew? [...] Buck O Perley suggested that "Many of the use cases that people are excited to use CTV for ([5], [6]) are very long term in nature and targeted for long term store of value in contrast to medium of exchange." But, if true, that's presumably incompatible with any sort of sunset that's less than many decades away, so doesn't seem much better than just having it be available on a signet? [5] https://github.com/kanzure/python-vaults/blob/master/vaults/bip119_ctv.py [6] https://github.com/jamesob/simple-ctv-vault If sunsetting were a good idea, one way to think about implementing it might be to code it as: if (DeploymentActiveAfter(pindexPrev, params, FOO) && !DeploymentActiveAfter(pindexPrev, params, FOO_SUNSET)) { EnforceFoo(); } That is to have sunsetting the feature be its own soft-fork with pre-declared parameters that are included in the original activation proposal. That way you don't have to have a second process debate about how to go about (not) sunsetting the rules, just one on the merits of whether sunsetting is worth doing or not. Cheers, aj