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 5E66CC002D for ; Sat, 17 Sep 2022 15:54:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 2644241DB3 for ; Sat, 17 Sep 2022 15:54:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2644241DB3 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=OB++fEBg X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 NP2KbF8EaH1q for ; Sat, 17 Sep 2022 15:54:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7624F41DB1 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp4.osuosl.org (Postfix) with ESMTPS id 7624F41DB1 for ; Sat, 17 Sep 2022 15:54:03 +0000 (UTC) Date: Sat, 17 Sep 2022 15:53:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1663430040; x=1663689240; bh=oYP8i0yWyA1K2Jtb6ToKaauE+/yOuJh1NtsxIkvcsZA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=OB++fEBgduoz7A8ZKkC3oWqixIn4xL1nqOjx0QQ1itWoka6AWyNCUll6gv1t/3s+X 6MnMKCBhWVqdkP2UWSiBS9R1VexSiUbu9RNZp/h1qkCLnUX1ogI+RKTKi9pS66K2Qm 3/cAAdlD0ZlGCNDNQ0xPJbZSW7kFTEE+0MtgBCP2QGuiFV88lvKUXb8//9t5EtXEkN sKL3u5Ln3FfURrugLcxkcBPEs8qZc8oOsLO6FUJeL2Zujha4/2oWFJfM8pY5I4wFA6 08cKWnvc4WfKJ1VdWGh/ZvhnP9ElK10o/gEveD8CLEdq9iLFeD5nSOrJuY1DRhoUsR 0sc0+0uk7kP/w== To: Matt Corallo , Bitcoin Protocol Discussion From: Michael Folkson Message-ID: <8cU3OEEtb7Q8CRBHqeWV6qe4JSRnOeMjh2PRdYj4rsnxF4DxzQd1Bo-1DAPMWGNxjXsZQuSuPrDK5TF4ez6tONZ5ACoLJ_FqV6Y1q7ybSwI=@protonmail.com> In-Reply-To: <8e4dc33b-2992-0380-de2a-0b8afa3db5b7@mattcorallo.com> References: <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com> <8e4dc33b-2992-0380-de2a-0b8afa3db5b7@mattcorallo.com> Feedback-ID: 27732268:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 17 Sep 2022 16:08:18 +0000 Cc: Anthony Towns 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 15:54:07 -0000 I agree with Matt. The less said about the "Aw shucks Jeremy didn't know th= at CTV didn't have community consensus at the time" [0] and "it was the lac= k of process that was the problem" the better. If people don't care about l= ack of community consensus there is no process in a permissionless, open so= urce community that can stop them or direct them down a more patient, produ= ctive path (I tried). I think it is a shame because I think (maybe I'm wron= g) at least in the technical community there is an understanding that long = term Bitcoin is far from finished in exhausting its potential and we do nee= d people who will work on changes that we'll need in the long term. There are a few interesting things in here though. I'm not convinced by the= name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the m= oment) but I do like the idea of signet having soft fork proposals enabled = on it [1] whether that be CTV, APO etc and if that requires more of the sig= net code to be moved out of the Core repo so be it. I'm surprised more isn'= t being done on Liquid already with what possible future functionality is (= and could be) enabled [2] there but maybe there is more happening than I'm = aware of. Protocols or use cases built out and demonstrated on signet (and/= or Liquid/sidechains) seem an obvious stepping stone to me for convincing t= he community that it is potentially worth taking the chain split risk for a= particular upgrade. It is a long slog to get community consensus on an upg= rade (Taproot certainly was a slog) but I think the vast majority of us thi= nk Taproot was worth that slog and Bitcoin would be poorer today without it= . The Great Consensus Cleanup is an interesting example in that I get Matt do= esn't have time to champion it or focus on it with his LDK commitments but = I have no idea where it would rank on his long term priority list if he was= n't working on LDK. Similarly I have no idea what people who understand thi= s evolving system much better than I do are thinking with regards to say ad= ding new opcodes, sighash flags versus say waiting on Simplicity and possib= ly adding new functionality within that potential upgrade. For people like = me who are extremely unlikely to propose their own consensus change(s) gett= ing some signal on what to spend time digging into would be useful rather t= han second guessing what people are thinking. There is a danger that you fl= irt with perceived public roadmaps when possible authority figures stick th= eir necks out and effectively say "I'm not in charge but in an imaginary wo= rld where I was this is my current thinking of the ordering in which we cou= ld improve this system long term. But this could change depending on x, y a= nd z and possible upgrades are only ready when they're ready and they have = community consensus." There is no way people don't play these exercises in = their minds. I do, I just have very few answers :) I personally think APO i= s in prime position to improve Lightning channel state management with elto= o and if it enables some covenant schemes too that seems like an added bonu= s. On APO versus waiting for APO like functionality in Simplicity I have no= idea. Work on APO/eltoo and Simplicity both seem to be progressing in para= llel so the APO versus Simplicity discussion perhaps rests on whether peopl= e think certain covenants should only really be enabled once we have the se= curity guarantees of Simplicity [3] (if at all). Antoine's covenant R&D effort [4] seems really promising and I hope the she= nanigans from earlier in the year don't put people off from engaging with t= hat. Hopefully we can see more exploration, development and research in cov= enants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways t= o Control the Future" [5]) and we can foster a community which has very hig= h standards, is open to new ideas and new research but can avoid these mont= hs long resisting chain split fights. I think the discussion would be much = more interesting and much more productive if people didn't have to think "I= f I express a view now it will be used to attack me personally later" or wo= rse "If I express a view now it will be used to justify an upcoming chain s= plit".=20 [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b71= 8 [1]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on= -signet-with-multiple-proposed-soft-forks-whilst-maintaining [2]: https://bitcoin.stackexchange.com/questions/109764/what-opcodes-are-su= pported-on-liquid-but-not-yet-on-bitcoin [3]: https://bitcoinops.org/en/topics/simplicity/ [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September= /020912.html [5]: https://arxiv.org/pdf/2006.16714.pdf -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ------- Original Message ------- On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev wrote: >=20 > On 9/17/22 2:14 AM, Anthony Towns wrote: >=20 > > On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev = wrote: > >=20 > > > On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote: > > >=20 > > > > 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. > >=20 > > Okay? "X is good" is obviously just a statement of opinion, so if you > > want to disagree, that's obviously allowed. > >=20 > > 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? >=20 >=20 > No, I think its at least a good chunk of the "statement of problem". Yes,= more testing is good, and > this project is a way to get that. Cool. But implying that lack of test f= rameworks is in any > material way part of the lack of movement on forks in Bitcoin I think is = very wrong, so its worth > pointing out, whether the particular project is useful or not is separate= . >=20 > > > Going back many, many years we've had many > > > discussions about fork process, and the parts people (historically) a= greed > > > with tend to be: > > > (1) come up with an idea > > > (2) socialize the idea in the technical community, see if anyone come= s up > > > with any major issues or can suggest better ideas which solve the sam= e > > > use-cases in cleaner ways > > > (3) propose the concrete idea with a more well-defined strawman, soci= alize > > > that, get some kind of rough consensus in the loosely-defined, subjec= tive, > > > "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 de= al 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 ha= ve > > > people who want to be champions who are willing to (humbly) push an i= dea > > > forward towards rough agreement of the world of technical bitcoiners > > > (without which I highly doubt you'd ever see broader-community consen= sus). > >=20 > > Personally, I think this is easily refuted by contradiction. > >=20 > > 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 >=20 >=20 > No? Who is the champion for it? I haven't been. No one else is obliged to= take up the reins and run > with it, that's not how open-source works. And no one has emerged who has= strong interest in doing > so, and that's totally fine. It means it hasn't made any progress, but th= at's an indication that no > one feels strongly enough about it that its risen to the top of their per= sonal priority list so > clearly doesn't need to make progress. >=20 > > 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. >=20 >=20 > No? Its not up to the community to find a champion for someone who wants = a fork to happen. Either > someone thinks its a good enough idea that they step up, or no one does. = If no one does, then so be > it. If the original proper (me, in this case) thought it was that importa= nt then its their > responsibility to be the champion, no one else's. >=20 > > 2) Many will argue that CTV has already done steps (1) through (3) abov= e: > > certainly there's been an idea, it's been socialised through giving tal= ks, > > having discussion forums, having research workshops [2], documenting us= e > > 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). >=20 >=20 > I don't really see how you can make this argument seriously. Honestly, if= a soft-fork BIP only has > one author on the list, then I'm not sure one can argue that step (3) has= really been completed, and > maybe not even step (2). >=20 > > So that leaves a few possibilities > > to my mind: >=20 > > * 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. > >=20 > > * 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. > >=20 > > * 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. >=20 >=20 > I think this is most of it, but its not that they're too hard, its that p= eople are too busy. There > seemed to be more positive feedback, for example, to Rusty's proposal, bu= t being the champion for a > soft-fork is a full-time job for months on end, and last I checked Rusty = has a lightning > implementation to maintain, which tends to be a more-than-full-time job a= lready. >=20 > To my knowledge, no one but Jeremy has made any serious attempt at being = the champion for a > soft-fork since Taproot, and before that Segwit (if someone reading this = who contributes to Core > already wants to, and isn't sure how to, there's lots of people who would= happily mentor you! I'm > sure you can figure out who to reach out to!). >=20 > Matt > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev