Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8F6A4C002D for ; Sun, 18 Sep 2022 12:28:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6479C4097F for ; Sun, 18 Sep 2022 12:28:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6479C4097F Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=c328DIVx X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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 TnFsZMlPpWVG for ; Sun, 18 Sep 2022 12:28:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 46EFC40111 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp2.osuosl.org (Postfix) with ESMTPS id 46EFC40111 for ; Sun, 18 Sep 2022 12:28:01 +0000 (UTC) Date: Sun, 18 Sep 2022 12:27:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1663504078; x=1663763278; bh=5ylRxnB6wvLwe8KXTK2l4aW24Fm+6dRU68QY9TUrZcQ=; 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=c328DIVxF/hdEzfMDw2Ipoj59Cu29XAHxVZHTegAYN4jrk0u+4XT3yTFwrx1xP23N kDgFDq5TeRoGqh4jYHgaCkWhSGBI69Bd0Zr4o+pTwY5HHkrdyTJYHdls5BMY2EXFX4 lVeXe2rbBD8RRi0odF2cFDVsk98g5WHLq/3qgwgzi6sz8suxcKCIUUHJu7TeV8IX5n C/F0BABftxOjCadCYskwO9tNgkMqJLfpJLOUgiTNXRwN9tydyGODr5rsgaZGS93xfE +BmF/X4aKOdT2o0Gj2l10VRjOypZwKHsw+q49JSIK4bc/el3KJhVI+jDjowpgcDPV1 NtB+GygIeYmEQ== To: Michael Folkson From: alicexbt Message-ID: In-Reply-To: <8cU3OEEtb7Q8CRBHqeWV6qe4JSRnOeMjh2PRdYj4rsnxF4DxzQd1Bo-1DAPMWGNxjXsZQuSuPrDK5TF4ez6tONZ5ACoLJ_FqV6Y1q7ybSwI=@protonmail.com> References: <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com> <8e4dc33b-2992-0380-de2a-0b8afa3db5b7@mattcorallo.com> <8cU3OEEtb7Q8CRBHqeWV6qe4JSRnOeMjh2PRdYj4rsnxF4DxzQd1Bo-1DAPMWGNxjXsZQuSuPrDK5TF4ez6tONZ5ACoLJ_FqV6Y1q7ybSwI=@protonmail.com> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 18 Sep 2022 16:51:20 +0000 Cc: Bitcoin Protocol Discussion , 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: Sun, 18 Sep 2022 12:28:04 -0000 Hi Michael, > I agree with Matt. The less said about the "Aw shucks Jeremy didn't know = that CTV didn't have community consensus at the time" [0] and "it was the l= ack of process that was the problem" the better.=20 The linked gist cannot be taken seriously and I am not sure why you keep sh= aring it as some document to prove there was no technical consensus for BIP= 119. Nadav has already mentioned this in the comments. If you care about c= ommunity consensus, maybe feedback about the links in that gist should also= be respected. There was chaos, misinformation and lot of drama on twitter.= Some people that opposed CTV on twitter still have no clue what CTV actual= ly does and a few were super enthusiastic because of the author for BIP 119= . > I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint,= let's park that for the moment) but I do like the idea of signet having so= ft fork proposals enabled on it [1] whether that be CTV, APO etc and if tha= t requires more of the signet code to be moved out of the Core repo so be i= t. Good to see some positivity, finally. Because tx introspection aka covenant= s would help everyone involved in bitcoin. This idea of experimenting with = soft forks on signet together with research and meetings suggested by Antoi= ne should help in better evaluation phase with less drama, politics etc. an= d more technical discussions to reach a goal. > 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.=20 1)Nobody uses Liquid. Signet has more activity than Liquid. 2)Testing something on Liquid will be completely different as its a separat= e blockchain with some similarities. I have summarized a few other positives of testing soft forks on signet bas= ed on AJ's email: a)Better evaluation b)PR implementing soft fork could be reviewed and merged outside core c)Testing on signet with pre-existing signet infrastructure d)Can deploy multiple consensus changes so easier to compare alternative ap= proaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc) e)Pre-baked ability to abandon the soft fork f)No need to regularly rebase consensus changes against bitcoin core's mast= er branch /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin-d= ev wrote: > I agree with Matt. The less said about the "Aw shucks Jeremy didn't know = that CTV didn't have community consensus at the time" [0] and "it was the l= ack of process that was the problem" the better. If people don't care about= lack of community consensus there is no process in a permissionless, open = source community that can stop them or direct them down a more patient, pro= ductive path (I tried). I think it is a shame because I think (maybe I'm wr= ong) at least in the technical community there is an understanding that lon= g term Bitcoin is far from finished in exhausting its potential and we do n= eed people who will work on changes that we'll need in the long term. >=20 > There are a few interesting things in here though. I'm not convinced by t= he name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the= moment) but I do like the idea of signet having soft fork proposals enable= d on it [1] whether that be CTV, APO etc and if that requires more of the s= ignet code to be moved out of the Core repo so be it. I'm surprised more is= n'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 (an= d/or Liquid/sidechains) seem an obvious stepping stone to me for convincing= the 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 u= pgrade (Taproot certainly was a slog) but I think the vast majority of us t= hink Taproot was worth that slog and Bitcoin would be poorer today without = it. >=20 > The Great Consensus Cleanup is an interesting example in that I get Matt = doesn't have time to champion it or focus on it with his LDK commitments bu= t I have no idea where it would rank on his long term priority list if he w= asn't working on LDK. Similarly I have no idea what people who understand t= his evolving system much better than I do are thinking with regards to say = adding new opcodes, sighash flags versus say waiting on Simplicity and poss= ibly adding new functionality within that potential upgrade. For people lik= e me who are extremely unlikely to propose their own consensus change(s) ge= tting some signal on what to spend time digging into would be useful rather= than second guessing what people are thinking. There is a danger that you = flirt with perceived public roadmaps when possible authority figures stick = their necks out and effectively say "I'm not in charge but in an imaginary = world where I was this is my current thinking of the ordering in which we c= ould improve this system > long term. But this could change depending on x, y and z and possible upg= rades 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 is in prime position t= o improve Lightning channel state management with eltoo and if it enables s= ome covenant schemes too that seems like an added bonus. On APO versus wait= ing for APO like functionality in Simplicity I have no idea. Work on APO/el= too and Simplicity both seem to be progressing in parallel so the APO versu= s Simplicity discussion perhaps rests on whether people think certain coven= ants should only really be enabled once we have the security guarantees of = Simplicity [3] (if at all). >=20 > Antoine's covenant R&D effort [4] seems really promising and I hope the s= henanigans from earlier in the year don't put people off from engaging with= that. Hopefully we can see more exploration, development and research in c= ovenants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways= to Control the Future" [5]) and we can foster a community which has very h= igh standards, is open to new ideas and new research but can avoid these mo= nths long resisting chain split fights. I think the discussion would be muc= h more interesting and much more productive if people didn't have to think = "If I express a view now it will be used to attack me personally later" or = worse "If I express a view now it will be used to justify an upcoming chain= split". >=20 > [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b= 718 > [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-= supported-on-liquid-but-not-yet-on-bitcoin > [3]: https://bitcoinops.org/en/topics/simplicity/ > [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septemb= er/020912.html > [5]: https://arxiv.org/pdf/2006.16714.pdf >=20 > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >=20 >=20 > ------- Original Message ------- > On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev = bitcoin-dev@lists.linuxfoundation.org wrote: >=20 >=20 >=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-de= v 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 activatio= n earlier > > > > > in the year [0], the question of "how to successfully get soft fo= rk > > > > > ideas from concept to deployment" doesn't really have a good answ= er 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 th= e > > > 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) maki= ng > > > it better, which would be worthwhile anyway? > >=20 > > No, I think its at least a good chunk of the "statement of problem". Ye= s, more testing is good, and > > this project is a way to get that. Cool. But implying that lack of test= frameworks is in any > > material way part of the lack of movement on forks in Bitcoin I think i= s very wrong, so its worth > > pointing out, whether the particular project is useful or not is separa= te. > >=20 > > > > 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 co= mes up > > > > with any major issues or can suggest better ideas which solve the s= ame > > > > use-cases in cleaner ways > > > > (3) propose the concrete idea with a more well-defined strawman, so= cialize > > > > that, get some kind of rough consensus in the loosely-defined, subj= ective, > > > > "technical community" (ie just ask people and adapt to feedback unt= il 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 bitcoiner= s > > > > (without which I highly doubt you'd ever see broader-community cons= ensus). > > >=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 th= e > > > past 3.5 years > >=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 h= as strong interest in doing > > so, and that's totally fine. It means it hasn't made any progress, but = that's an indication that no > > one feels strongly enough about it that its risen to the top of their p= ersonal 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 it= s > > > 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 coul= d > > > have taken it over in that timeframe. > >=20 > > No? Its not up to the community to find a champion for someone who want= s 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 impor= tant 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) ab= ove: > > > certainly there's been an idea, it's been socialised through giving t= alks, > > > 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 alternativ= e > > > approaches have been suggested [3], none of them have even really mad= e > > > it to step (2), let alone step (3). > >=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) h= as 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 > > I think this is most of it, but its not that they're too hard, its that= people are too busy. There > > seemed to be more positive feedback, for example, to Rusty's proposal, = but being the champion for a > > soft-fork is a full-time job for months on end, and last I checked Rust= y has a lightning > > implementation to maintain, which tends to be a more-than-full-time job= already. > >=20 > > To my knowledge, no one but Jeremy has made any serious attempt at bein= g the champion for a > > soft-fork since Taproot, and before that Segwit (if someone reading thi= s who contributes to Core > > already wants to, and isn't sure how to, there's lots of people who wou= ld 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 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev