One of the strongest arguments against BIP110 is that it restricts certain transactions based on their use case and therefore constitutes a form of censorship. This argument is easier to understand if we imagine a different context: suppose the targeted use case were a privacy tool such as CoinJoin, and the group attempting to prevent its use in Bitcoin were widely recognized as hostile to Bitcoin—for example, a CIA proxy seeking to ban privacy-preserving transactions. If Bitcoin accepts arbitrary restrictions on certain use cases, it could create a dangerous precedent. Looking more closely at this argument, however, reveals some important nuances. First, Bitcoin has repeatedly disabled certain features or opcodes in the past, primarily because of security concerns or because they lacked legitimate usage. OP_IF may fall into this category, as it appears to be used almost exclusively for data storage rather than for its intended purpose. The other changes proposed by BIP110 follow the same pattern: they target features that are not known to be needed for legitimate non-data-storage use cases. Opponents argue that these features might become useful in the future. However, by that logic, Bitcoin should also preserve or even add countless other opcodes that nobody currently needs, just in case they might one day become useful. This argument therefore appears relatively weak. Historically, Bitcoin has already established the precedent that unused features posing security risks or enabling harmful behavior can be removed. This leaves the remaining criticism: BIP110 is explicitly designed to target a particular use case—data storage. That is, of course, exactly its purpose. The discussion therefore shifts to a different question: should large-scale arbitrary data storage be supported by Bitcoin? If the answer is no, the next question becomes how it should be reduced. Eliminating it entirely has never been claimed to be possible. On the first question, however, there appears to be overwhelming agreement, including among many opponents of BIP110, that excessive arbitrary data storage is not a desirable use of Bitcoin. The remaining debate is therefore about the means. Opponents argue that arbitrary data storage cannot be prevented because closing one avenue simply causes users to switch to another. For example, encoding data in public keys has always been possible and cannot realistically be mitigated. This is a strong argument, but it also raises several questions. If public-key abuse has always been possible, why did the explosion in arbitrary data storage only occur after Taproot? Are different storage methods associated with different costs, efficiencies, or practical limitations? Even without knowing every technical detail, it seems very likely that they are. If that is the case, then removing the preferred methods will not eliminate arbitrary data storage, but it can certainly make it less convenient, less efficient, and more expensive. In addition, repeatedly adapting to protocol changes imposes costs and friction on businesses built around storing arbitrary data on Bitcoin, making their long-term business model less attractive to investors. A cat-and-mouse game may therefore still be worthwhile. Combined with a clear social signal that large-scale data storage is unwelcome—a healthy degree of “toxicity” toward blockchain spam—it increases both the economic and social costs of pursuing such activities. Taken together, the censorship argument becomes much less convincing. Excessive arbitrary data storage is not a legitimate use case in the eyes of the overwhelming majority of Bitcoiners. While it cannot be eliminated completely, forcing spammers into a continual cat-and-mouse game raises their costs far more than Bitcoin’s. Finally, removing features that have no meaningful use beyond enabling spam follows a pattern that Bitcoin has already established in the past without those changes generally being regarded as censorship.

An important and compelling argument against the BIP110 soft fork is that it sets a dangerous precedent by allowing a minority to push through changes. However, this argument has two weak points. First, BIP110 supporters are not necessarily a minority. Most Bitcoiners are likely either not informed enough about the proposal or simply not interested, making them effectively neutral. The relevant question is therefore: how large is the anti-BIP110 camp compared to the pro-BIP110 camp? While this is difficult to answer with certainty, the available evidence suggests that the pro camp is larger than the anti camp. If so, it cannot reasonably be described as a minority. This is especially notable given the censorship on many of the most relevant Bitcoin discussion platforms. Second, even if BIP110 supporters were ultimately found to be a minority relative to the anti-BIP110 camp, that outcome would have to be viewed in the context of the extensive censorship they faced. As @hodlonaut clearly documented, freedom of speech on the issue was not intact. Therefore, the “minority” argument is only persuasive if both sides had a fair opportunity to present their case, which was demonstrably not the case.