Re: [bitcoin-dev] User Resisted Soft Fork for CTV

From: "Jorge Timón" <jtimon@jtimon•cc>
To: Michael Folkson <michaelfolkson@protonmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Date: Sat, 23 Apr 2022 22:40:19 +0200	[thread overview]
Message-ID: <CABm2gDpb4LmLh3LMy1Z4uAWyKp-9AqUKc2DzcxZa7VPqqUVddQ@mail.gmail.com> (raw)
In-Reply-To: <RyYBRY3MJP_0b2YkCEUFBdP8u1A_cGSEEkDbzKK9k-rkINZrBaOL70L96iHR11bJhmkhAzuN6uZ1X8PQgz2wa8Us3-2OpNa4RbhSSprw_WE=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 3496 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 7415 bytes --]