Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 05C90C002D for ; Sun, 24 Apr 2022 12:57:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id D951C415E3 for ; Sun, 24 Apr 2022 12:57:19 +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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com 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 5IMIc-7fMAz8 for ; Sun, 24 Apr 2022 12:57:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by smtp4.osuosl.org (Postfix) with ESMTPS id E144C415CE for ; Sun, 24 Apr 2022 12:57:17 +0000 (UTC) Received: by mail-yb1-xb2b.google.com with SMTP id b95so22587252ybi.1 for ; Sun, 24 Apr 2022 05:57:17 -0700 (PDT) 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=N3hyWZiggbBZ++oO/QCHNQia85ppVkqXk1Ch94HRfJA=; b=Ij0lfi6XTKIVc3xJHDwUzjZhhtf4WnpPC3U+ntZrxYWyAAamwfIZV7JSWJIhXx6HT5 mNJz0DyqHwUBgadzAXdB4TOJq+3itv/gjf2tDpqMJQP2oAIhCPaKWTTQqcIEcuLG0WsZ +HnU6XrS4wU9Sn3xbw439nXFJms7lwZJK2R/EJ896Lm4jntKjHqB6eDJG8s2ahUSwMbF bHTfmMIf5EN7D4NxSyHOIHfvo8lp8CXGymb2CZZ50Sbm/hS16XyPfnQYGc8fYNOlVmfL 8UjUDvEJsNRzXL98BoZyT1Bnl9lVxxC27nAhaclfHY+lvvo+sCI5LvmqpB/fPkfoOFlB RGFQ== 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=N3hyWZiggbBZ++oO/QCHNQia85ppVkqXk1Ch94HRfJA=; b=nIY7XKbCvNuB++ITyLIoLM9xkWZgBdk0TnUEBx9HKTBt6Yq5hps6Pil20Xc/Yv1siQ Dok+BfRrGNQV0yhKsqtqIZmTBLC6yThpbAWSCqfOi72/vh95irlC9+XNKtGXUCp6KBcl JSIjcO+UZuAZzp/QbNeTNhsixv3exaY+AA9ZsrBBkMxbnG2Q19pVpxHdiH968ui/zhiG oFpt5leCuBh2e9Koyk2De58OLsMyc+dYanwlLorDJs8Z3d20cLLigtfjdISC50bXG7Nm S3/c2DmzV0/CwUsq+Gef3bMfbro5y6SaIbBOPnlOO29rrGy2WSZN6GWssW1xxtHA8JA4 NNhQ== X-Gm-Message-State: AOAM5303o6txV9RDv2/yLMCgbfouE4ZMlUFogLzIBLsns1uvPLjI924i v79r90+MJ/cmIfZAuuZR0SqR1/uwr+j4mZBsSiD9lQ== X-Google-Smtp-Source: ABdhPJx8WkNCLjOU9uzthM9de1mnH3gwAf/MksgV3xtxtOFZviXKXGx2f+9Nnek+BNwmWWZJANIsO+hNcBVTcDeeZ9E= X-Received: by 2002:a25:107:0:b0:645:d3ed:3cb7 with SMTP id 7-20020a250107000000b00645d3ed3cb7mr9932878ybb.26.1650805036689; Sun, 24 Apr 2022 05:57:16 -0700 (PDT) MIME-Version: 1.0 References: <8Yt-4vl30FWFAmOwRD8j1gcY7tQjZNaOnyPGJ_iO4XaCtwwGHkS4JIjxj6up34f1akjIAbggV3lP18WDIZ31MoMnOxwyjzTZtNsd5T0bBP0=@protonmail.com> In-Reply-To: <8Yt-4vl30FWFAmOwRD8j1gcY7tQjZNaOnyPGJ_iO4XaCtwwGHkS4JIjxj6up34f1akjIAbggV3lP18WDIZ31MoMnOxwyjzTZtNsd5T0bBP0=@protonmail.com> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Sun, 24 Apr 2022 14:57:05 +0200 Message-ID: To: Michael Folkson Content-Type: multipart/alternative; boundary="000000000000ce36d905dd65ff80" X-Mailman-Approved-At: Sun, 24 Apr 2022 18:57:46 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] User Resisted Soft Fork for CTV 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, 24 Apr 2022 12:57:20 -0000 --000000000000ce36d905dd65ff80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson < michaelfolkson@protonmail.com> wrote: > Hi Jorge > > > Can we agree now that resisting a bip8 proposal is simpler and cleaner > than resisting a speedy trial proposal? > > Personally I'd rather stick to one challenge at a time :) Currently we ar= e > facing a contentious soft fork activation attempt of CTV using an > alternative client which we expect [1] to be a Speedy Trial deployment. > Once this is resolved we can discuss the lessons and observations that co= me > out of this. > That sounds reasonable to me. Fair enough. > > Is there any PR to actively resist the proposal on bitcoin core? > > Not currently. Unless this becomes really, really messy and starts to pos= e > a true existential threat to Bitcoin itself I think it best that attempts > to actively resist the proposal are done outside of Bitcoin Core in an > alternative client(s). Contrary to what some CTV proponents say getting > anything consensus related into Bitcoin Core is extremely difficult > (especially at short notice). There is no BDFL or Linus Torvalds like > figure, there are a large number of contributors (and maintainers) who al= l > have differing personal views. Hence directing people to have this > discussion on a particular PR in the Bitcoin Core repo seems to me to be > counterproductive and a massive distraction to other work that is going o= n > on Bitcoin Core. We've already started to see online attacks on Bitcoin > Core by CTV proponents [2] claiming an "old guard trying to assert > dictatorship over the Bitcoin protocol". It is nonsense of course but > directing that nonsense to the Bitcoin Core repo is surely not the right > way to go. > > As I've said in previous emails there is a Libera (and Freenode now) IRC > channel ##ursf that has been set up to discuss an alternative client. We'= ll > get a conversation log up too. And of course we wait for confirmation on > what the Speedy Trial deployment parameters for this attempted CTV soft > fork are going to be. > > [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/ > [2]: > https://twitter.com/ProofOfKeags/status/1517574210691887105?s=3D20&t=3D_j= gRh3kkYP3kn1qLuzGXrQ > > I disagree that it shouldn't be on bitcoin core, but I guess such a proposal would get many nacks. But if there are no speedy trial parameters yet, I guess we need to wait for that; whether the code for resisting it ends up in bitcoin core or not. Thanks for the clarifications. -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > ------- Original Message ------- > On Saturday, April 23rd, 2022 at 21:40, Jorge Tim=C3=B3n > wrote: > > I've been calling them "controversial softforks" for long. > I hate to be right some times, but I guess I'm happy that I'm not the onl= y > one who distrusts jeremy rubin anymore. > > Can we agree now that resisting a bip8 proposal is simpler and cleaner > than resisting a speedy trial proposal? > I guess now we don't need to discuss it in hypothetical terms anymore, do > we? > > Is there any PR to actively resist the proposal on bitcoin core? > > > > > > > On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Ok so we've had to scramble a bit as I don't think anyone except perhaps >> Jeremy thought that there would be a Speedy Trial signaling period for a >> CTV soft fork planned to start on May 5th [1]. That is two weeks away. >> >> (I have to take what he says at face value. I can understand why one >> would be skeptical.) >> >> Understandably this has angered and surprised a few people including som= e >> of those who have voiced opposition to a CTV soft fork activation being >> attempted in the first place [2]. >> >> As I've said in a previous post [3] the Bitcoin Core 23.0 release >> candidate (and older versions) does not include any CTV code or CTV >> activation code. If a miner runs Bitcoin Core 23.0 out the box it will n= ot >> signal for CTV. If by some chance CTV was to activate through some other >> software release Bitcoin Core releases would not apply CTV rules but the= y >> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to >> prepare for an eventuality where the miner signaling threshold might be >> reached but the community wants to prevent the attempted soft fork from >> activating. (I personally don't think a 90 percent miner signaling >> threshold will be reached but I wouldn't want to bet Bitcoin's future on >> it.) >> >> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) >> but I'm open to better names. I certainly don't want to discourage those >> who dislike or oppose UASFs from contributing to this effort and >> potentially ultimately running a URSF release. If you don't want this >> rushed CTV soft fork to activate we are all on the same side whatever we >> call it. >> >> For now I've set up a ##ursf channel on Libera IRC to monitor >> developments and discuss working on an additional release that if run ma= y >> ultimately reject blocks that signal for CTV. >> >> The intention of this would be to provide additional direction and >> incentive to miners that the community does not want this soft fork to b= e >> activated. To repeat running a Bitcoin Core release will not signal for = a >> CTV soft fork out the box. If a miner runs a Bitcoin Core release it wil= l >> not signal for CTV. >> >> Apologies that this is rushed. But as always with Jeremy caution and >> conservatism seems to be thrown out the window and we have to react to >> that. It goes without saying that this is not how Bitcoin consensus chan= ges >> should be attempted. >> >> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/ >> [2]: >> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 >> [3]: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/02023= 5.html >> >> -- >> Michael Folkson >> Email: michaelfolkson at protonmail.com >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > --000000000000ce36d905dd65ff80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 24, 2022 at 2:17 PM Micha= el Folkson <michaelfolk= son@protonmail.com> wrote:
Hi Jorge<= /div>

>=C2=A0Can= we agree now that resisting a bip8 proposal is simpler and cleaner than re= sisting a speedy trial proposal?

Personally I'd = rather stick to one challenge at a time :) Currently we are facing a conten= tious soft fork activation attempt of CTV using an alternative client which= we expect [1] to be a Speedy Trial deployment. Once this is resolved we ca= n discuss the lessons and observations that come out of this.
<= /blockquote>

That sounds reasonable to me. Fair enough.<= br>
=C2=A0
&g= t;=C2=A0Is there any PR to actively resist t= he proposal on bitcoin core?

Not currently. Unless this becomes really, really = messy and starts to pose a true existential threat to Bitcoin itself I thin= k it best that attempts to actively resist the proposal are done outside of= Bitcoin Core in an alternative client(s). Contrary to what some CTV propon= ents say getting anything consensus related into Bitcoin Core is extremely = difficult (especially at short notice). There is no BDFL or Linus Torvalds = like figure, there are a large number of contributors (and maintainers) who= all have differing personal views.=C2=A0Hence directing people to have this discussion on a particular PR in th= e Bitcoin Core repo seems to me to be counterproductive and a massive distr= action to other work that is going on on Bitcoin Core.=C2=A0We've already started to see online = attacks on Bitcoin Core by CTV proponents [2] claiming an "old guard t= rying to assert dictatorship over the Bitcoin protocol". It is nonsens= e of course but directing that nonsense to the Bitcoin Core repo is surely = not the right way to go.

= As I've said in previous emails there is a Libera (and Freenode now) IR= C channel ##ursf that has been set up to discuss an alternative client. We&= #39;ll get a conversation log up too. And of course we wait for confirmatio= n on what the Speedy Trial deployment parameters for this attempted CTV sof= t fork are going to be.

=
<= br>
I disagree that it shouldn't be on bitcoin core, but I gu= ess such a proposal would get many nacks.
But if there are no= speedy trial parameters yet, I guess we need to wait for that; whether the= code for resisting it ends up in bitcoin core or not.
Thanks= for the clarifications.


------- Original Message -------
On Saturday, April 23rd, 2022 at 21:40, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wr= ote:

I've been calling them "controve= rsial softforks" for long.
I hate to be right some times, bu= t I guess I'm happy that I'm not the only one who distrusts jeremy = rubin anymore.

Can we agree now that resisting a b= ip8 proposal is simpler and cleaner than resisting a speedy trial proposal?=
I guess now we don't need to discuss it in hypothetical = terms anymore, do we?

Is there any PR to actively = resist the proposal on bitcoin core?






On Thu, Apr 21, 2022 at 8:16 PM M= ichael Folkson via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:
Ok so we've had to scramble a bit as I don't think anyone ex= cept perhaps Jeremy thought that there would be a Speedy Trial signaling pe= riod for a CTV soft fork planned to start on May 5th [1]. That is two weeks= away.

(I have to take what he says at = face value. I can understand why one would be skeptical.)

Understandably this has angered and surprised a few pe= ople including some of those who have voiced opposition to a CTV soft fork = activation being attempted in the first place [2].

As I've said in a previous post [3] the Bitcoin Core 23.0 r= elease candidate (and older versions) does not include any CTV code or CTV = activation code. If a miner runs Bitcoin Core 23.0 out the box it will not = signal for CTV. If by some chance CTV was to activate through some other so= ftware release Bitcoin Core releases would not apply CTV rules but they als= o wouldn't reject blocks that apply CTV rules. Hence it is prudent to p= repare for an eventuality where the miner signaling threshold might be reac= hed but the community wants to prevent the attempted soft fork from activat= ing. (I personally don't think a 90 percent miner signaling threshold w= ill be reached but I wouldn't want to bet Bitcoin's future on it.)<= /div>

I've tentatively labelled this ef= fort a User Resisted Soft Fork (URSF) but I'm open to better names. I c= ertainly don't want to discourage those who dislike or oppose UASFs fro= m contributing to this effort and potentially ultimately running a URSF rel= ease. If you don't want this rushed CTV soft fork to activate we are al= l on the same side whatever we call it.

For now I've set up a ##ursf channel on Libera IRC to monitor developm= ents and discuss working on an additional release that if run may ultimatel= y reject blocks that signal for CTV.

Th= e intention of this would be to provide additional direction and incentive = to miners that the community does not want this soft fork to be activated. = To repeat running a Bitcoin Core release will not signal for a CTV soft for= k out the box. If a miner runs a Bitcoin Core release it will not signal fo= r CTV.

Apologies that this is rushed. B= ut as always with Jeremy caution and conservatism seems to be thrown out th= e window and we have to react to that. It goes without saying that this is = not how Bitcoin consensus changes should be attempted.


--
Michael Folks= on
Email: michaelfolkson at proton= mail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9= 835 92D6 0159 214C FEE3
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<= /a>
https://lists.linuxf= oundation.org/mailman/listinfo/bitcoin-dev

--000000000000ce36d905dd65ff80--