It will definitely have higher order effects that the filter team doesn’t quite appreciate. They want to wish away the economic game theory that makes Bitcoin work, and by my observation it’s a desire to end run a consensus level conversation (should these transactions be allowed to exist?), and short cutting that discussion by only doing a policy level change. People are now advocating for whitelisted script templates in the effort to stop this stuff, everyone is losing the plot on what makes Bitcoin bitcoin. Let the miners get their massive stack of bitcoin while people speculate. You can think all of the inscriptions are spam, and accept nothing can be done and focus your efforts on what you want to do in Bitcoin, and that acceptance isn’t an endorsement.

Replies (1)

I think that both "filter teams" I mentioned (OCEAN-led datacarriersize proposal and Chaincodelabs-led bare-multisig proposal) are skeptical of important higher order effects of updating current Core's filter due to the fact that current Core's filter seamingly didn't produce such effects, and the new proposals don't change their fundamental logic. The stronger arguments I've seen about why these new updates would be worse are actually by the team proposing to remove non-fee-based filters from Core completely. But I'm quite sure that would have important higher order effects as well. I'm not sure Luke or Murch want to wish away any economic game theory, but it's clear it's not a game theory "that makes Bitcoin work", since Core currently filters away high-fee-paying txs from mempool. I think is entirely reasonabe on their part to suggest only mempool-level upgrades and not soft fork: mempool policy is a matter of local preference, relatively safe & dynamic, block validity is a matter of global consensus, very risky, hard to change and very hard to change back once changed. So far the only one I've seen suggesting a consensus change was a malicious troll by an "ordinals" developer, trying to lure anti-spam users into running a disastrous fork without even an activation date (I don't remember his name, but he's friend with some Bitcoiners so he gets a pass for such irresponsible behavior, sadly). In general, managing something as dynamic as spam with consensus rules seems frankly crazy to me. Spam attacks and DDoS are preferable to consensus failures and splits. Bitcoin deva always advocated for whitelisted script templates, nothing new: currently Core stansardness rule explicitly whitelist 5 types of txs, while all the other possible types are nonstandard, regardless of the fees. Not having whitelists in mempool policies is *most definitely not* "what makes Bitcoin bitcoin". I can't prevent malicious or apatic miners get their massive stack of fees coming from "NFT" frauds and spam attacks: I can just refuse to cooperate actively and shame them publicly. I absolutely agree with you that one can think all of the inscriptions are spam, and accept nothing can be done about it. It may be the case. One could also think that something may be done to some degree (as I suspect) but that it's still better to focus efforts on other things: totally honest and respectable take.