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

From: Michael Folkson <michaelfolkson@protonmail•com>
To: Keagan McClelland <keagan.mcclelland@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Date: Fri, 22 Apr 2022 09:53:25 +0000	[thread overview]
Message-ID: <9HxOgQTZiQzQR4bOCusxMr4dqbLst7p6j_vqwrlsiDY6ya8Y6EaspWwdea2dUwxh8gntGaoqaNXj5Eyafn7Qam_GB98SAdLvtuYd8rAG_Qk=@protonmail.com> (raw)
In-Reply-To: <CALeFGL1=4PrA_ziTsoS9sUjGjfLr54AiMfM99uDV-Bau5Ab_eQ@mail.gmail.com>

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

I'm going to keep this short as I'm sure you are not interested in discussion on supposedly "unhinged" takes. Plus I know you support this soft fork activation attempt, you have heard the arguments from various people against attempting it and if you don't believe by now that soft forks should have community consensus before they are attempted nothing will convince you.

> Resisting changes that don't affect you

The consensus rules are essentially what define Bitcoin. Bitcoin is nothing without well defined and rarely changing consensus rules. If they can be changed by a subset of the community against the wishes of another subset of the community then we may as well accept that all soft fork proposals will eventually get activated because all soft fork proposals will be able to get a subset of the community to support them. (There are a lot of proposals out there.) Decentralized decision making requires that we collectively set high bars when considering making changes to the most important and dangerous part of Bitcoin. Once consensus rules are changed they generally need a hard fork to revert. This is Bitcoin 101. I really shouldn't need to explain this to you. There was a lot of work done by a large number of people to slowly build community consensus around Taproot. You seem to be arguing that that work was pointless because ultimately Taproot doesn't affect the community. If you don't like it don't use it right? Just keep quiet? Nothing to do with you? Gosh....

> You've gone from saying you won't NACK the proposal on its own to intentionally cause consensus forks to block its enforcement.

Can you provide a link? If there was community consensus a single NACK from me would be pointless. I'm assuming that's the context in which it was said. I've been consistent on wanting community consensus before any soft fork is attempted. If there is community consensus it doesn't matter what I think. This is not a proposal that currently has community consensus and you are seeking to attempt to activate it anyway. Look at some of the individuals on this list. Only yesterday Matt Corallo, Adam Back, Murch, Bob McElrath etc were arguing online this should not be attempted. Perhaps you want to call their takes "unhinged" too?

https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718

I'm happy to discuss anything with those who are on the fence or who are genuinely trying to come to a view on this. But I won't be responding again to people like Jeremy, Keagan etc who I know perfectly well understand these arguments, ignore them and proceed regardless.

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

------- Original Message -------
On Friday, April 22nd, 2022 at 12:36 AM, Keagan McClelland <keagan.mcclelland@gmail•com> wrote:

> Good day Michael,
>> and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV.
> This seems silly to me.
>
> The structure of CTV is imbuing an OP_NOP with script semantics. Resisting changes that don't affect you is not consistent with the ideals of people being able to structure their own private agreements as they see fit...aka freedom. It seems needlessly coercive to try and resist CTV in this way. CTV is ultimately an opt-in proposal. If you don't like the risk/benefit ratio, you can simply not generate scripts that contain CTV checks. Conservatism and apathy are something I can understand, but resisting CTV via an escalating soft fork is not conservatism or apathy, it's fundamental opposition. What is it that you hope to accomplish by blocking others from using a new opcode? According to your formal statement, you haven't really opposed CTV on fundamental grounds so much as vaguely questioning whether or not it is the "best tool for the job"...as if anyone really has the capacity to judge that for a diverse group with varying interests and use cases that may differ substantially from their own.
>
> There are really two ways to effectively resist this change: 1. reject all blocks during the lockin period, 2. reject all blocks that include OP_CTV in the script.
>
> Regardless of which method you choose, it is ultimately going to be a far more forceful/invasive consensus change than CTV was in the first place. So have fun trying to explain yourself out of that one. You've gone from saying you won't NACK the proposal on its own to intentionally cause consensus forks to block its enforcement. Did you change your mind or something?
>> 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.)
>
> Making the statement that "the community doesn't want this to activate" as if it's some kind of foregone conclusion is a pretty bold claim. I think you'll be surprised at how broad support actually is. To contrast your second citation, here's the set of people who have endorsed the proposal, along with a handful of people opposed (such as yourself): https://utxos.org/signals/. If you are aware of others who are opposed, it would be worth your time to solicit a statement from them that can be put on the signals page. Absent that, it seems appropriate to assume that the overwhelming majority of people who have opined on the subject are for it.
>> 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.
>
> What an unhinged take. The level of effort put into gathering consensus for CTV has set the bar higher than Taproot. Taproot didn't have the level of outreach effort that CTV does, and the complexity in taproot is significantly larger than for CTV. You didn't seem to have a problem organizing that activation process. That proposal was opened for public discussion in Jan'20, merged in Oct'20, and you were organizing activation discussions as early as Jan'21. The design of CTV has been *final* since Feb'20, a month after Taproot was opened for public discussion. There's a ton of Proof-of-Concept code that has been written to test out use cases for CTV, but for Taproot it still doesn't look like we'll have MuSig for a while longer (I heard a year, but someone can correct me on that if I'm wrong), and wallet support for Taproot wasn't fleshed out until after activation. Characterizing Jeremy's efforts as throwing caution and conservatism out the window is hypocritical at best and malicious at worst.
>
> Finally, I think it is worth stating that if Bitcoin adopts a culture where a willfully ignorant set of people can block changes that have no impact on them, despite a large constituency wanting those changes, then Bitcoin kind of deserves the slow deterioration that will result from that. I don't really find that future appealing and so I think that trying to find ways to activate non-invasive changes should be everyone's goal, *even if* they personally may not have an immediate use case, or have a slight preference for alternate solutions. The exception to this is any introduction of systemic risk. Not all soft-forks are equal, and therefore the meta-consensus requirements for getting them activated should vary based on how broadly consequential the change is.
>
> Feel free to resist this if you want. In some sense that's what the Speedy Trial procedure is for. However, I think your case would be more compelling if you actually had some sort of affirmative argument for why CTV induces systemic risk to non-users of the opcode. Expressing uncertainty over whether it is the globally optimal solution (to a problem that cannot be globally defined due to diverse interests) is not persuasive to me and many others in the community.
> Keagan
>
> On Thu, Apr 21, 2022 at 12: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](http://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: 20919 bytes --]