Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 67317C002D for ; Sat, 23 Apr 2022 20:40:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 45F5D60B4A for ; Sat, 23 Apr 2022 20:40:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTI1JbWChqeE for ; Sat, 23 Apr 2022 20:40:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by smtp3.osuosl.org (Postfix) with ESMTPS id 02A1260AB9 for ; Sat, 23 Apr 2022 20:40:31 +0000 (UTC) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-2ef5380669cso115904967b3.9 for ; Sat, 23 Apr 2022 13:40:31 -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; bh=2kMPUZj//oA7XZnIFn9ayo3X8UB4cIsIUf88fggN4Ck=; b=03vK77LOFwXpmw/DgM8CdEFKp2ueA33Wpnyf0tWQtmXw+bsAESl4vWWAQ5wXeDwEI5 TZEYnt/Iy+u3G5Qe6nBesUC0rAyWefQdz6m3UdZ3tTdfZeM530zwLGtOE2nj0HBNwVmK qqzobKDcN48ArtLH8ewePLMTajxjPEtX1h8sIymfF1M1FOdEuUwnypYNBBHWzG+WimGQ zSscM8DZUqUpTwzoRaZS7n6PG27MFSgbPyIhRbfSmk6U7SIHIoP/paQp+kil0JNgSGKS ZZWjxcFplAK2bBSWZFvYzkgkkrh4QkAKDFnOIcyuuubVpU9DQEfRIFnvLrTJo4+AjHDu 1kJw== 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; bh=2kMPUZj//oA7XZnIFn9ayo3X8UB4cIsIUf88fggN4Ck=; b=H/beRN6P/Pir1C02VngfeEQuB4Eo0fRD2l7+wPalvUiVIO5bV1rw52ax5BjqDswcRp ZR5zqx/gYeOhODDtxQTaSchcFIbWaDd7Ggg0SEOFumkLiYMZBaOj3uAU421VewpbPVch U9o8dGnF7Q2ZMheko1BWagdneN+GrtZoDAL5wPK8n2GhqQccem+n7i3sSyNXgI+BXSma ByeuKEPncpyBcnSWbuSV4IlcSY5bp21VfDI4vfCxaSLU2Bh1aZljWbq/5vCJBsiA1tMd c/wufuCH1UzVS71nEPJ62i5c5Kiu3Ek9oieleBfYWQJ7DfjpMCloD7aB5MN5sFxkLSeU w0yw== X-Gm-Message-State: AOAM532VQ7NAhAOGonLhNzQQeSqUiZ857xz3JoaL56lYZ4cv+NyGfuGP 2yCnVWc+ze287rMOAIGbV5GkOuqQ16cyfJkhBFN0XQ== X-Google-Smtp-Source: ABdhPJxvf4J4WorUT7v0otNV4EzW5RQ8tucip83J8QA0DcCYHHcHMsMLmK2oVfm3tellsI5dzKtlWfXmjJZZuBNFd74= X-Received: by 2002:a0d:d80b:0:b0:2f7:c74f:7ca5 with SMTP id a11-20020a0dd80b000000b002f7c74f7ca5mr4154855ywe.489.1650746430733; Sat, 23 Apr 2022 13:40:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Sat, 23 Apr 2022 22:40:19 +0200 Message-ID: To: Michael Folkson , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000009e5cb905dd585ac0" X-Mailman-Approved-At: Sat, 23 Apr 2022 21:38:02 +0000 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: Sat, 23 Apr 2022 20:40:33 -0000 --0000000000009e5cb905dd585ac0 Content-Type: text/plain; charset="UTF-8" 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 only 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 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 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 not > 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 they > 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 may 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 be > 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 will > 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 changes > 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/020235.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 > --0000000000009e5cb905dd585ac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been calling them "controversial softfo= rks" for long.
I hate to be right some times, but I guess I&= #39;m happy that I'm not the only one who distrusts jeremy rubin anymor= e.

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 anymor= e, do we?

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



=



On Thu, Apr 21, 2022 at 8:16 PM Michael Folks= on via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Ok so we've had to scramble a bit as I don't think a= nyone except perhaps Jeremy thought that there would be a Speedy Trial sign= aling period for a CTV soft fork planned to start on May 5th [1]. That is t= wo 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 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 release candidate (and older versions) does not include any CTV code o= r CTV activation code. If a miner runs Bitcoin Core 23.0 out the box it wil= l not signal for CTV. If by some chance CTV was to activate through some ot= her software release Bitcoin Core releases would not apply CTV rules but th= ey also wouldn't reject blocks that apply CTV rules. Hence it is pruden= t to prepare for an eventuality where the miner signaling threshold might b= e reached but the community wants to prevent the attempted soft fork from a= ctivating. (I personally don't think a 90 percent miner signaling thres= hold will be reached but I wouldn't want to bet Bitcoin's future on= it.)

I've tentatively labelled thi= s 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 ar= e all on the same side whatever we call it.

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

The intention of this would be to provide additional direction and incent= ive to miners that the community does not want this soft fork to be activat= ed. 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 will not signa= l for CTV.

<= div style=3D"font-family:arial;font-size:14px">Apologies that this is rushe= d. But as always with Jeremy caution and conservatism seems to be thrown ou= t the window and we have to react to that. It goes without saying that this= is not how Bitcoin consensus changes should be attempted.

--0000000000009e5cb905dd585ac0--