diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2022-04-21 11:39:17 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-21 18:39:24 +0000 |
| commit | 2e070eee80b8c72644c7a94a8de21a6c78d912e0 (patch) | |
| tree | 792b205dc4d154a094decc90b5bacc830ebd400b /29 | |
| parent | 37953bb3f79afa497a6ba651447031ca0a3abb68 (diff) | |
| download | pi-bitcoindev-2e070eee80b8c72644c7a94a8de21a6c78d912e0.tar.gz pi-bitcoindev-2e070eee80b8c72644c7a94a8de21a6c78d912e0.zip | |
Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
Diffstat (limited to '29')
| -rw-r--r-- | 29/ac7945de0f3c4da47d2da9544329f4b51a7d16 | 148 |
1 files changed, 148 insertions, 0 deletions
diff --git a/29/ac7945de0f3c4da47d2da9544329f4b51a7d16 b/29/ac7945de0f3c4da47d2da9544329f4b51a7d16 new file mode 100644 index 000000000..92c9db79b --- /dev/null +++ b/29/ac7945de0f3c4da47d2da9544329f4b51a7d16 @@ -0,0 +1,148 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 4F0C6C002C + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <lf-lists@mattcorallo.com>) + id 1nhbi1-000CPS-M1; Thu, 21 Apr 2022 18:39:17 +0000 +Message-ID: <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com> +Date: Thu, 21 Apr 2022 11:39:17 -0700 +MIME-Version: 1.0 +Content-Language: en-US +To: "David A. Harding" <dave@dtrt.org> +References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> + <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com> + <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> +From: Matt Corallo <lf-lists@mattcorallo.com> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + |