From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 36B1CC002D for ; Sat, 17 Sep 2022 06:14:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E955483E66 for ; Sat, 17 Sep 2022 06:14:18 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E955483E66 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ig8WAknUdGc for ; Sat, 17 Sep 2022 06:14:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9AB1983E5F Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9AB1983E5F for ; Sat, 17 Sep 2022 06:14:17 +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 1oZR5f-0000xa-24; Sat, 17 Sep 2022 16:14:13 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Sat, 17 Sep 2022 16:14:05 +1000 Date: Sat, 17 Sep 2022 16:14:05 +1000 From: Anthony Towns To: Matt Corallo , Bitcoin Protocol Discussion Message-ID: References: <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com> X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet 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: Sat, 17 Sep 2022 06:14:19 -0000 On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev wrote: > On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote: > > As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier > > in the year [0], the question of "how to successfully get soft fork > > ideas from concept to deployment" doesn't really have a good answer today. > I strongly disagree with this. Okay? "X is good" is obviously just a statement of opinion, so if you want to disagree, that's obviously allowed. I also kind of feel like that's the *least* interesting paragraph in the entire email to talk further about; if you think the current answer's already good, then the rest of the mail's just about (hopefully) making it better, which would be worthwhile anyway? > Going back many, many years we've had many > discussions about fork process, and the parts people (historically) agreed > with tend to be: > (1) come up with an idea > (2) socialize the idea in the technical community, see if anyone comes up > with any major issues or can suggest better ideas which solve the same > use-cases in cleaner ways > (3) propose the concrete idea with a more well-defined strawman, socialize > that, get some kind of rough consensus in the loosely-defined, subjective, > "technical community" (ie just ask people and adapt to feedback until you > have found some kind of average of the opinions of people you, the > fork-champion, think are reasonably well-informed!). > (4) okay, admittedly beyond this is a bit less defined, but we can deal with it when we get there. > Turns out, the issue today is a lack of champions following steps 1-3, we > can debate what the correct answer is to step (4) once we actually have > people who want to be champions who are willing to (humbly) push an idea > forward towards rough agreement of the world of technical bitcoiners > (without which I highly doubt you'd ever see broader-community consensus). Personally, I think this is easily refuted by contradiction. 1) If we did have a good answer for how to progress a soft-fork, then the great consensus cleanup [0] would have made more progress over the past 3.5 years. Maybe not all of the ideas in it were unambiguously good [1], but personally, I'm convinced at least some of them are, and I don't think I'm alone in thinking that. Even if the excuse is that its original champion wasn't humble enough, there's something wrong with the process if there doesn't exist some other potential champion with the right balance of humility, confidence, interest and time who could have taken it over in that timeframe. 2) Many will argue that CTV has already done steps (1) through (3) above: certainly there's been an idea, it's been socialised through giving talks, having discussion forums, having research workshops [2], documenting use cases use cases; there's been a concrete implementation for years now, with a test network that supports the proposed feature, and new tools that demonstrate some of the proposed use cases, and while alternative approaches have been suggested [3], none of them have even really made it to step (2), let alone step (3). So that leaves a few possibilities to my mind: * CTV should be in step (4), and its lack of definition is a problem, and trying the "deal with it when we get there" approach is precisely what didn't work back in April. * The evaluation process is too inconclusive: it should either be saying "CTV is not good enough, fix these problems", or "CTV hasn't sufficiently demonstrated its value/cost, work on X next", but it isn't. * Parts (2) to (3) are too hard, and that's preventing alternatives from making progress, which in turn is preventing people from being able to decide whether CTV is the superior approach, or some alternative is. But each of those possibilities indicates a significant problem with our answer for developing soft forks. I guess my belief is that it's mostly (2) and (3) being too hard (which taproot overcame because many were excited about it, and CTV overcame because Jeremy's put a lot of effort into it; but consensus cleanup, APO, simplicity, TXHASH, etc have not similarly overcome at this point), which leads to the evaluation process being inconclusive when plausible alternatives exist. (In particular, I think having the process be massively difficult is going to naturally cause any "humble" champion to decide that they're not up to the task of following the process through to completion) Anyway, that's some additional reasons why I believe what I said above, in case that's interesting. But like I said at the start, if you still disagree, that's fine of course. Cheers, aj [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html https://github.com/bitcoin/bitcoin/pull/15481 https://github.com/bitcoin/bitcoin/pull/15482 [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016765.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016763.html https://github.com/bitcoin/bitcoin/pull/15482#issuecomment-469822630 [2] https://utxos.org/workshops/ [3] TXHASH https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html TX https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html Elements-style opcodes https://twitter.com/rusty_twit/status/1518007923896578048 cf https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019851.html ANYPREVOUT? https://twitter.com/darosior/status/1474375301262151684 Simplicity? https://twitter.com/Mario_Gibney/status/1403890965903859718 Lisp? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020036.html