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