From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4F0C6C002C for ; Thu, 21 Apr 2022 18:39:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 2DEA040A6E for ; Thu, 21 Apr 2022 18:39:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 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_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=mattcorallo.com 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 4Shsn2C9v5JO for ; Thu, 21 Apr 2022 18:39:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by smtp2.osuosl.org (Postfix) with ESMTPS id DF672400B8 for ; Thu, 21 Apr 2022 18:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mattcorallo.com; s=1650564063; h=In-Reply-To:From:References:Cc:To:Subject: From:Subject:To:Cc:Reply-To; bh=WCY5o3kJEzjkU8X9qA58ZvEsPfPHalu0T6cJCVd+b6E=; b=QVPFEEw3n3sqZjkhc/41rayK+yumqM6MSUvvC/WxdpiQDvpcEbi8ck9itPmSM1NLE7yhpGd3xug vxPNP9UUpVXcMJiKBMgRLpS9QLGc6XLbFjM276KuseHEKCRuxY9zmWa8s6l3NzyfKjKNRcP9uFRHK 8FClnWR6IMxq4I/aEYBQNkK+mHT4eT5zpnO+q1IJ9R3hp2dXDNDG+mRzNA1cc570tY9IS1vMx+B+C KtXEuxHuhuBNiaA9Nb01sZ2VKBkPJTdt3FyUDdYlosQglJDGvKGfvnicjBs43M2536nrar/IqIEkV +PIaeBCzOAQ6JdoXMfxRZApvTUkpbCF2sHyA==; Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1nhbi1-000CPS-M1; Thu, 21 Apr 2022 18:39:17 +0000 Message-ID: Date: Thu, 21 Apr 2022 11:39:17 -0700 MIME-Version: 1.0 Content-Language: en-US To: "David A. Harding" References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> From: Matt Corallo In-Reply-To: <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/mattcorallo.com X-DKIM-Note: For more info, see https://as397444.net/dkim/ 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:39:24 -0000 On 4/21/22 11:06 AM, David A. Harding wrote: > 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. No, its unrelated to whether CTV or any other system gets usage. If we were just concerned with whether CTV would get usage over or under some other alternative proposal then I could see an argument for your proposal (though the nontrivial cost of any fork to Bitcoin would make me still strongly disagree with such a way forward in principle). Rather, I'm instead concerned with us designing something that is going to be the most flexible and useful and hopefully private covenents design we can, because that doesn't just get users to use the change to Bitcoin we paid some nontrivial change-cost to incorporate into the Bitcoin's consensus rules, but gets the most bang-for-our-buck. There are at least three or four separate covenants designs that have been posted to this list, and I don't see why we're even remotely talking about a specific one as something to move forward with at this point. We don't add things to Bitcoin just to find out whether we can. full stop. We add things to Bitcoin because (a) there's some demonstrated use-cases and intent to use the change (which I think we definitely have for covenants, but which only barely, if at all, suggests favoring one covenant design over any other), (b) because its generally considered aligned with Bitcoin's design and goals, based on developer and more broad community response and (c) because the technical folks who have/are wiling to spend time working on the specific design space think the concrete proposal is the best design we have, and finally (d) because the implementation is well-reviewed and complete. I do not see how we can make an argument for any specific covenant under (c) here. We could just as well be talking about TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use CTV can probably just as easily use those instead - ie this has nothing to do with "will people use it". >> 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 That all seems fine, except that doing a fork on Bitcoin has very nontrivial cost, both in terms of ecosystem disruption and possibility that anything goes wrong, not to mention code maintenance (which we cannot remove the validation code for something ever, really - you still want to be able to validate the historical chain). Plus, really, I'd love to see "technical community consensus" somewhere in there - at least its been something that has very roughly appeared for most previous soft forks, at least among those who have time/willingness to work on the specific design being proposed. [other comments snipped because my responses would mostly have been rehashing the first response above]. Matt