I'm shocked at the amount of people in bitcoin proposing mempool policy changes without understanding second/third order consequences, or even worse, thinking they know but are wrong.

Replies (7)

Bitcoin social media is a lot like fiat politics. The loudest voices are the most highly regarded and it's obvious they don't know what they're talking about.
Uh? The only radical mempool policy change proposal I see (removing incentive-incompatible filters entirely) are from Peter Todd and Ben Carman, but don't seem to have much following. Milder, more conservative proposals come from Luke Dashjr in Knots & disrespector-patch promoters in Core (extending to tapscript the very same datacarriersize policy that Core uses for pre-taproot txs) and Mark Erhardt (filtering out bare multisig in Core as well, as Knots already does since year). All minority views. Do you hear about anything else?
Thank you for answering one-off even if blocked elsewhere (I block very liberally on Twitter, here it's neither possible nor needed). The proposal you list is the second "type" I mention in my brief list. The higher order effect you mention (increasing already present offband auctions of blockspace) would be common between that and the third "type" (Much's proposal to filter out bare multisig, apparently popular among Core devs). But since Core already filters high-fee-paying valid txs, it seems to me that, at least in principle, the first "type" is the only proposal that would avoid that higher order effect completely...not the status quo. Even if I find it likely that the umprecedented move to a total lack of mempool filtering could produce way more/bigger higher order effects.
I mostly see people yelling because he's claiming that even in the case of the inflation bug, it would be legit bug fixing to change the documentation to align with the (buggy) code. But maybe we have a different follow-list so we see different yelling.
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.
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.