On Activation
I think the reason that it’s considered blasphemy for miners to activate is a misunderstanding of the asymmetry of soft vs. hard forks. If we take all three components of Rusty’s maxim, the third (users override) allows users to intervene, should any miner impropriety take place.
The issue with the block size wars is two fold. First was that the 2MBHF is a hard-fork, forcing old nodes out of consensus, which is an aggressive maneuver. Second, the change being proposed imposed significant (+100%) ongoing resource costs with cumulative storage requirements.
Miners are and always have been responsible for administrating consensus updates. Whether we like it or not, miners are already capable of executing a “progressive soft-fork” by just censoring transactions that violate the new soft-fork rules.
For this reason I believe the position of universally rejecting MASF’s that some people seem to be taking is willfully ignorant of the capabilities and risks Bitcoin actually has in favor of amplifying the drama of the block size debate. I believe this is a mind virus that Bitcoin MUST overcome if it’s going to succeed.
Miners imposing their own interests on the community is a real risk and in certain circumstances we should be able to coordinate action in rejecting malicious changes, but allowing them to fulfill the responsibility of smooth consensus upgrades via BIP8/9 is quite reasonable.
The main argument I hear against BIP9 (LOT=F) is that it “gives miners the ability to override the will of users”. This is not what is going on. What it does is tells miners that we have decent-ish enough consensus that we want this thing to be activated but not enough to hold you by the nuts to do it. If they reject it under this arrangement then there’s nothing to stop the community from actually mobilizing a LOT=T deployment and trying again. In fact, I’m nigh certain that this would happen as it would trigger a lot of people into getting out their LOT=T pitchforks.
On Readiness
However, all of this is a bit premature as it seems that the current debate is not HOW to deploy a soft-fork, like was the case with taproot, but what even constitutes consensus when it comes to deciding “yes we should, in principle, activate this thing”.
There are a variety of types of soft-forks and this is where the discussion gets nuanced enough that I fear it is increasingly going to be inaccessible to the average node-runner. Some soft-forks are purely non-invasive. They do not impact existing users’ use of Bitcoin in any way other than subtly changing the global economy of Bitcoin by granting users opt-in capabilities. If one takes the position that any change that subtly impacts Bitcoin’s global properties needs to benefit all users of Bitcoin, then you can generalize that to changes in relay policy, custodial wallets, new financial products etc. This position is not tenable. Thinking through this idea invariably leads to ossification and ossification will invariably lead to a flippening as at some point the properties of coins that are allowed to change will represent a greater value proposition than Bitcoin’s maximal commitment to stability via ossification.
There are other soft-forks that seriously impact the whole Bitcoin economy (reducing the block reward) which meaningfully change the Bitcoin social contract for everyone. These types of soft-forks would be advisable for users to reject, should miners try to implement them sneakily.
As such, imo, there is only one real valid reason to reject a soft fork and that is saying that there are existing users whose existing coins would behave differently than they planned for when they created the utxo.
From this point the main thing that has to be figured out is how to tell whose arguments are correct when it comes to describing how the proposal impacts those users. Again, proving the utility of a change is not necessary for this step, proving safety of the existing usage of the system is. This process I believe to be fairly easy to do rigorously, as you’d be able to demonstrate by contradiction why the new change burns someones coins or changes the semantics in a way that leaves them vulnerable to theft.
As far as utility goes, making utility arguments is a good way to get people interested and interest is how we get review. If things are sufficiently reviewed and deemed to be safe then the review interest alone is enough to demonstrate the utility. Obviously not all reviews/reviewers carry equal sway and that will continue to be true in perpetuity. Regardless, more review implies more interest.
On Process
I want to offer one final idea with regards to the process of changing consensus. It is perhaps a good idea to work backwards from the activation rather than forwards from the proposal.
I think there is a pretty strong consensus that we should do some kind of soft-fork in the future. I think also that there is strong consensus that we probably want it sooner than 4 years after the last one. I think even further that there is pretty overwhelming technical consensus that some form of covenants are desirable. Where there seems to be substantial disagreement is precisely which covenant proposal is best or whether we just want to wait an indeterminate period of time for yet another covenant proposal to emerge.
I think it’s possible to improve both the speed of development as well as promote cooperation among developers and reviewers by saying “We want a 2025 soft-fork, it will happen, what’s in that soft-fork is TBD but whatever is going needs to have sufficient review and we roughly agree on the north star of what we want to accomplish with it.”
Make no mistake, this is a brinksmanship tactic. But if we can collectively agree to engage in that brinksmanship then maybe it may actually force us to get out of the stands and into the arena to make sure that we can come to an agreement on something that will actually improve Bitcoin, rather than slowly letting it atrophy and brain drain as we lose more brilliant devs to technology projects (cryptocurrency or otherwise) that actually have a possibility of impact.
Bitcoin’s success is not pre-ordained. We need to figure this out.