From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9A47EC002C for ; Thu, 21 Apr 2022 18:06:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 80919409E4 for ; Thu, 21 Apr 2022 18:06:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EUbV-Aiy5Fn for ; Thu, 21 Apr 2022 18:06:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5]) by smtp2.osuosl.org (Postfix) with ESMTPS id 4C0F5409DD for ; Thu, 21 Apr 2022 18:06:17 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id D7EDA280005E; Thu, 21 Apr 2022 11:06:14 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Thu, 21 Apr 2022 11:06:14 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 21 Apr 2022 08:06:14 -1000 From: "David A. Harding" To: Matt Corallo In-Reply-To: References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> User-Agent: Roundcube Webmail/1.4.10 Message-ID: <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 6918.62619d16.d3665.0 Cc: Bitcoin Protocol Discussion 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: Thu, 21 Apr 2022 18:06:18 -0000 On 21.04.2022 04:58, Matt Corallo wrote: > On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote: >> The main criticisms I'm aware of against CTV seem to be along the >> following lines: >> >> 1. Usage, either: >>   a. It won't receive significant real-world usage, or >>   b. It will be used but we'll end up using something better later >> 2. An unused CTV will need to be supported forever, creating extra >> maintenance >>    burden, increasing security surface, and making it harder to >> evaluate later >>    consensus change proposals due to their interactions with CTV > > Also "is this even the way we should be going about covenants?" I consider this to be a version of point 1b above. If we find a better way for going about covenants, then we'll activate that and let CTV automatically be retired at the end of its five years. If you still think your point is separate from point 1b, I would appreciate you helping me understand. > the Bitcoin technical community (or at least those interested in > working on covenants) doesn't even remotely show any signs of > consensus around any concrete proposal, This is also my assessment: neither CTV nor any other proposal currently has enough support to warrant a permanent change to the consensus rules. My question to the list was whether we could use a transitory soft fork as a method for collecting real-world usage data about proposals. E.g., a consensus change proposal could proceed along the following idealized path: - Idea (individual or small group) - Publication (probably to this list) - Draft specification and implementation - Riskless testing (integration tests, signet(s), testnet, etc) - Money-at-stake testing (availability on a pegged sidechain, an altcoin similar to Bitcoin, or in Bitcoin via a transitory soft fork) - Permanent consensus change > talking about a "way forward for CTV" or activating CTV or coming up > with some way of shoving it into Bitcoin at this stage [...] sets > incredibly poor precedent for > how we think about changes to Bitcoin and maintaining Bitcoin's > culture of security and careful design. How should we think about changes to Bitcoin and maintaining its culture of security and careful design? My post suggested a generalized way we could evaluate proposed consensus changes for real-world demand, allowing us to settle what I see as the most contended part of the CTV proposal. That feels to me like legitimate engineering and social consensus building. What would be your preferred alternatives? (For the record, my preferred alternative for years has been to add the technically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what covenant-y things people build with them, and then consider proposals to optimize the onchain usage of those covenant-y things. Alas, this seems to fall afoul of the concerns held by some people about recursive covenants.) > I'm gobsmacked that the conversation has reached this point, and am > even more surprised that the response from the Bitcoin (technical) > community hasn't been a more resounding and complete rejection of this > narrative. If the only choices are to support activation of BIP119 CTV at this time or to reject it, I would currently side with rejection. But I would prefer over both of those options to find a third way that doesn't compromise safety or long-term maintainability and which gives us the data about CTV (or other covenant-related constructions) to see whether the concerns described above in 1a and 1b are actually non-issues. I see one of those third ways as the testing on the CTV signet described in a contemporaneous thread on this list.[1] Other third ways would be trying CTV on sidechains or altcoins, or perhaps allowing CTV to be temporarily used on Bitcoin as proposed in this thread. Is there interest in working on those alternatives, or is the only path forward an argument over attempting activation of CTV? Thanks, -Dave [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html