Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A80CDC001D for ; Thu, 10 Mar 2022 11:40:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 97CCB8438B for ; Thu, 10 Mar 2022 11:40:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com 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 O2yHPkneK_KB for ; Thu, 10 Mar 2022 11:40:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by smtp1.osuosl.org (Postfix) with ESMTPS id 17BFB84374 for ; Thu, 10 Mar 2022 11:40:50 +0000 (UTC) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-2db2add4516so54728257b3.1 for ; Thu, 10 Mar 2022 03:40:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NBO86emH6SpUa8IurkNyLCrM7l78CfngNr2uWTVZFJU=; b=uJhr7xnvabHfP2nxugKdpwsjhJgjAQ57y0XSJ60cjHzCkRgfCGhVu5lvgHGX8XlkQv doMtvo8Qgy/mXgud8HgIyPZJLpiMpNIUhR1Hj2AqESl7vvqlOl2hCFoKX7LyEiL2wKwo 8ENqqULVnYkl4wf6unGwYwY+Ly93tdr3akx7M9NCV4nrqrTYPr+2XtFB+VcpRgkrVrzC siELo7A0PmVwBEN+RTnGoPepJfhDptq9sgfGInPAIJxpzlQOB361G9dtYxaGgZZMlMqM 6hKXbLXgdvflRD4w+q4ih4NSnm1vzh7SLjD5YmB9LqoVHacUJofQ8sx6em0ZbxgtYAPw Gnaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NBO86emH6SpUa8IurkNyLCrM7l78CfngNr2uWTVZFJU=; b=zS33PLZuEOEpqN7OW2yuPriC9UM90/GfmVGGf+pQXMMtrZld+nUBFbkO6El7jWDS0R nhB5nc5C9pIj3/XaMa9Pzl8e7BGPc7kvsVxsxMQ5++fGz0uDa4TLZnyYq5RospdBQP23 hWYUKu7z1RaCS9lG85iUh607GPxrbkzEQOxsrVL2erVX1dsWl4ZlrPdfzmbDkbb/HPcn 6j5TmuBqvY/MWG8NQgv5JEwQMZryVTVDm6zeNLqi3iD86UXTDJsGQf8aY5iSkgDI7xTF XAFA4WcopHIaDn8wNv6xCb8jHABRuvTkoE8AEIhuc9d2e7RU6TFGZ8ugqfoQl7x8JYOb wkvA== X-Gm-Message-State: AOAM5333/sXUiXEMDCzzTPH0QOAiyxrZAarYvPitwb3a2Y7abIwb9f8F tJvU0xGd0+2soiEac3tH/vMY1nWgSioOVK2birmEE5sOvHpGwQ== X-Google-Smtp-Source: ABdhPJz8EympKkpNdwSOP8ypHpAuny6XMqC/Ts6rqysRt/8jS9Uv2mqaVEpnIEZGNo00vkT3emPv0ppbrwnTFHOt0Mc= X-Received: by 2002:a0d:e88d:0:b0:2dc:108e:b184 with SMTP id r135-20020a0de88d000000b002dc108eb184mr3399998ywe.240.1646912449928; Thu, 10 Mar 2022 03:40:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Thu, 10 Mar 2022 11:41:52 +0000 Message-ID: To: Michael Folkson Content-Type: multipart/alternative; boundary="0000000000008df52605d9dbafa3" X-Mailman-Approved-At: Thu, 10 Mar 2022 13:04:30 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT) 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, 10 Mar 2022 11:40:52 -0000 --0000000000008df52605d9dbafa3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 9, 2022, 14:14 Michael Folkson wrote: > Hi Jorge > > > Since this has meetings like taproot, it seems it's going to end up > being added in bitcoin core no matter what. > > Anyone can set up a IRC channel, anyone can organize a IRC meeting, anyon= e > can announce meetings on the mailing list. Just because an individual is > enthusiastic for a soft fork proposal does not imply it has community > consensus or that it is likely to be merged into Core in the short term o= r > long term. It is true that other soft fork proposal authors/contributors > are not taking the approach Jeremy is taking and are instead working > quietly in the background. I prefer the latter approach so soon after > Taproot activation but I look forward to hearing about the progress made = on > other proposals in due course. > I hope you're right and not every proposal that gets to have a meeting gets deployed. > Should we start the conversation on how to resist it when that happens? > We should talk more about activation mechanisms and how users should be > able to actively resist them more. > > I can only speak for myself but if activation was being pursued for a sof= t > fork that didn't have community consensus I would seek to join you in an > effort to resist that activation. Taproot (pre-activation discussion) set= a > strong precedent in terms of community outreach and patiently building > community consensus over many years. If that precedent was thrown out I > think we are in danger of creating the chaos that most of us would seek t= o > avoid. You are free to start whatever conversation you want but personall= y > until Jeremy or whoever else embarks on an activation attempt I'd rather > forget about activation discussions for a while. > I strongly disagree taproot set a strong precedent in terms of listening to criticism and looking for consensus. Lots of legitimate criticisms seemed to be simply ignored. I really think it set a bad preference, even if taproot as deployed is good, which I'm not sure about. > What is ST? If it may be a reason to oppose CTV, why not talk about it > more explicitly so that others can understand the criticisms? > > ST is short for Speedy Trial, the activation mechanism used for Taproot. = I > have implored people on many occasions now to not mix discussion of a sof= t > fork proposal with discussion of an activation mechanism. Those discussio= ns > can happen in parallel but they are entirely independent topics of > discussion. Mixing them is misleading at best and manipulative at worst. > Thanks. Yes, those topics were ignored before "let's focus on the proposal first" and afterwards "let's just deploy this and we can discuss this in more detail for the next proposal". And I thonk lots of valid criticism was ignored and disregarded. > It seems that criticism isn't really that welcomed and is just explained > away. > Perhaps it is just my subjective perception. Sometimes it feels we're > going from "don't trust, verify" to "just trust jeremy rubin", i hope thi= s > is really just my subjective perception. Because I think it would be real= ly > bad that we started to blindly trust people like that, and specially jere= my. > > I think we should generally avoid getting personal on this mailing list. > However, although I agree that Jeremy has done some things in the past th= at > have been over-exuberant to put it mildly, as long as he listens to > community feedback and doesn't try to force through a contentious soft fo= rk > earlier than the community is comfortable with I think his work can add > material value to the future soft fork discussion. I entirely agree that = we > can't get into a situation where any one individual can push through a so= ft > fork without getting community consensus and deep technical review from a= s > many qualified people as possible. That can take a long time (the demands > on long term contributors' time are vast) and hence anyone without seriou= s > levels of patience should probably exclusively work on sidechains, altcoi= ns > etc (or non-consensus changes in Bitcoin) rather than Bitcoin consensus > changes. > You're right, we shouldn't get personal. We shouldn't ignore feedback from me, mark friedenbach or luke just because of who it comes from. I don't think jeremy listens to feedback, judging from taproot activation discussions, I felt very much ignores by him and others. Luke was usually ignored. Mark criticisms on taproot, not the activation itself, seemed to be ignored as well. I mean, if somebody refuted his concerns somewhere, I missed it. But even if I believe jremey has malicious intentions and doesn't listen to the community, you're still right, we shouldn't get personal. I shoud assume the same malevolent intentions I assume jeremy has from everyone else. Thanks > Michael > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > ------- Original Message ------- > On Wednesday, March 9th, 2022 at 11:02 AM, Jorge Tim=C3=B3n via bitcoin-d= ev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Since this has meetings like taproot, it seems it's going to end up being > added in bitcoin core no matter what. > > Should we start the conversation on how to resist it when that happens? > We should talk more about activation mechanisms and how users should be > able to actively resist them more. > > > On Tue, Mar 8, 2022, 03:32 Jeremy Rubin via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> * Tuesday, March 8th. >> >> I think Noon PT =3D=3D 8pm UTC? >> >> but dont trust me i cant even tell what day is what. >> -- >> @JeremyRubin >> >> >> On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin >> wrote: >> >>> Hi all, >>> >>> There will be a CTV meeting tomorrow at noon PT. Agenda below: >>> >>> 1) Sapio Taproot Support Update / Request for Review (20 Minutes) >>> - Experimental support for Taproot merged on master >>> https://github.com/sapio-lang/sapio >>> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes) >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/0= 19879.html >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/= 018168.html >>> 3) Jamesob's Non-Recursive Vaults Post (20 minutes) >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/0200= 67.html >>> 4) What the heck is everyone talking about on the mailing list all of >>> the sudden (30 minutes) >>> - EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc >>> 5) Q&A (30 mins) >>> >>> Best, >>> >>> Jeremy >>> >>> >>> -- >>> @JeremyRubin >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > --0000000000008df52605d9dbafa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 9, 2022, 14:14 Michael Folkson <michaelfolkson@protonmail.com= > wrote:
Hi Jorge

>= =C2=A0Since this has meetings like taproo= t, it seems it's going to end up being added in bitcoin core no matter = what.

Anyone can set up a IRC ch= annel, anyone can organize a IRC meeting, anyone can announce meetings on t= he mailing list. Just because an individual is enthusiastic for a soft fork= proposal does not imply it has community consensus or that it is likely to= be merged into Core in the short term or long term. It is true that other = soft fork proposal authors/contributors are not taking the approach Jeremy = is taking and are instead working quietly in the background. I prefer the l= atter approach so soon after Taproot activation but I look forward to heari= ng about the progress made on other proposals in due course.=C2=A0

= I hope you're right and not every proposal that gets to have a meeting = gets deployed.

>=C2=A0Should we start the conversation on how to resist it when that ha= ppens?
We should talk more about activation me= chanisms and how users should be able to actively resist them more.<= /span>

I can only spea= k for myself but if activation was being pursued for a soft fork that didn&= #39;t have community consensus I would seek to join you in an effort to res= ist that activation. Taproot (pre-activation discussion) set a strong prece= dent in terms of community outreach and patiently building community consen= sus over many years. If that precedent was thrown out I think we are in dan= ger of creating the chaos that most of us would seek to avoid. You are free= to start whatever conversation you want but personally until Jeremy or who= ever else embarks on an activation attempt I'd rather forget about acti= vation discussions for a while.

I strongly disagree taproot set a s= trong precedent in terms of listening to criticism and looking for consensu= s. Lots of legitimate criticisms seemed to be simply ignored.
I really think it set a bad preference, even if taproot as deploy= ed is good, which I'm not sure about.

=
> Wh= at is ST? If it may be a reason to oppose CTV, why not talk about it more e= xplicitly so that others can understand the criticisms?
<= br>
ST is short for Speedy Trial, the activation mechanis= m used for Taproot. I have implored people on many occasions now to not mix= discussion of a soft fork proposal with discussion of an activation mechan= ism. Those discussions can happen in parallel but they are entirely indepen= dent topics of discussion. Mixing them is misleading at best and manipulati= ve at worst.

Thanks. Yes, those topics were ignored b= efore "let's focus on the proposal first" and afterwards &quo= t;let's just deploy this and we can discuss this in more detail for the= next proposal".
And I thonk lots of valid crit= icism was ignored and disregarded.


> It seems = that criticism isn't really that welcomed and is just explained away.
=
Perhaps it is just my subjective perce= ption. Sometimes it feels we're going from "don't trust, verif= y" to "just trust jeremy rubin", i hope this is really just = my subjective perception. Because I think it would be really bad that we st= arted to blindly trust people like that, and specially jeremy.
=

I thin= k we should generally avoid getting personal on this mailing list. However,= although I agree that Jeremy has done some things in the past that have be= en over-exuberant to put it mildly, as long as he listens to community feed= back and doesn't try to force through a contentious soft fork earlier t= han the community is comfortable with I think his work can add material val= ue to the future soft fork discussion. I entirely agree that we can't g= et into a situation where any one individual can push through a soft fork w= ithout getting community consensus and deep technical review from as many q= ualified people as possible. That can take a long time (the demands on long= term contributors' time are vast) and hence anyone without serious lev= els of patience should probably exclusively work on sidechains, altcoins et= c (or non-consensus changes in Bitcoin) rather than Bitcoin consensus chang= es.

You're right, we shouldn't get personal. We shouldn'= ;t ignore feedback from me, mark friedenbach or luke just because of who it= comes from.
I don't think jeremy listens to fee= dback, judging from taproot activation discussions, I felt very much ignore= s by him and others. Luke was usually ignored. Mark criticisms on taproot, = not the activation itself, seemed to be ignored as well. I mean, if somebod= y refuted his concerns somewhere, I missed it.
But e= ven if I believe jremey has malicious intentions and doesn't listen to = the community, you're still right, we shouldn't get personal. I sho= ud assume the same malevolent intentions I assume jeremy has from everyone = else.

Thanks
Michael
--
Michael FolksonEmail: michaelfolkson at protonmail.c= om
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 = 214C FEE3

------- Original Message -------
On Wednesday, March 9th, 2022 at 11:02 AM, Jorge Tim=C3=B3n via bit= coin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:

Since this has meetings like taproot, it seem= s it's going to end up being added in bitcoin core no matter what.

Should we start the conversation o= n how to resist it when that happens?
We should talk= more about activation mechanisms and how users should be able to actively = resist them more.


On Tue, Mar 8, 2022, 03:= 32 Jeremy Rubin via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
* Tuesday, March 8th.

I think Noon PT =3D=3D 8pm UTC?

but don= t trust me i cant even tell what day is what.


On Mon, Mar 7, 20= 22 at 6:50 PM Jeremy Rubin <jeremy.l.= rubin@gmail.com> wrote:
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r= gb(0,0,0)" class=3D"gmail_default">Hi all,

There will be a CTV = meeting tomorrow at noon PT. Agenda below:

1) Sapio Taproot Support Update / Request for Review (20 Minutes)<= /div>
- Experimental support for Taproot me= rged on master https://github.com/sa= pio-lang/sapio
2) Transa= ction Sponsoring v.s CPFP/RBF (20 Minutes)
- https://lists.linuxfoundation.org/pipermail/bitcoi= n-dev/2022-February/019879.html
- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/= 2020-September/018168.html
3) = Jamesob's Non-Recursive Vaults Post (20 minutes)
4) What the heck is everyone talking about on the mailing list al= l of the sudden (30 minutes)
-= EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc
5) Q&A (30 mins)

Best,

Jeremy


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoun= dation.org
https://l= ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--0000000000008df52605d9dbafa3--