> Framing this as only policing your own node overlooks the network externalities If I set up a fence around my house, that has neighborhood externalities. My neighbors can't see one another by looking across my lawn, for instance. But framing "anything with externalities" as "policing" the people it has an effect on is problematic. Just as it is not my responsibility to ensure that my two neighbors can see one another across my lawn, it is also not my responsibility to ensure that miners get their blocks to my peers quickly. I may decide to help some or all of them do that; but even if I do make such a decision, it is not as if that puts me in some position of responsibility where I cannot now apply filters to transactions that I *don't* want in my mempool and *don't* want to assist with. > Your definition on what transactions should be allowed...is not a filtering policy; it's an argument for a hard fork. Those things are not incompatible. One could theoretically propose something as a mempool filter *and* as a hard fork; the nice thing about mempools is, they do not require consensus to modify, so you can just do it. Whereas a hard fork is very hard precisely because unless you get a whole bunch of people to agree with you (i.e. get consensus) you end up just creating an independent network (not that there's anything wrong with that, unless you start scamming people with it) If I *did* propose this for a fork, it would be a soft fork, not a hard one, as it would require *tightening* the rules, not loosening them. But it would have some of the same *effects* as a hard fork if it was contentious, because contentious softforks (theoretically) split the network into incompatible branches just like hard forks do. That said, while I don't want to entirely close the door on a soft fork, I think it is wise, for the aforesaid reasons, to just do it in my own mempool, and tell other interested people (if any) how to do it in theirs -- because I don't need consensus for that and I get all the benefits I seek as a result and I also make less people mad. > The current Bitcoin consensus explicitly allows these transactions, and has for years. To enforce your narrow definition network-wide, you would need to change the fundamental rules of the protocol. Nice that I don't *want* to enforce my definition network-wide, then. But we've been over similar ground moments ago; perhaps you think that slightly slowing block propagation speed among my peers counts as "enforcing my definition network-wide." If so, I disagree, and I'd particularly like to highlight that this slowdown doesn't even affect how fast my *peers* receive a block unless *my* connection with a given peer would otherwise be their fastest available connection. (If they've got peers A, B, and Me, and peer A is faster than me anyway, then it doesn't matter that I have to download some transactions before serving them a block -- they were gonna get the block faster from peer A anyway.) And, in my personal case, I very much doubt that I am anyone's fastest connection, as I personally operate on pretty bad wifi that I find in hostels and airbnbs. > This brittle definition would not only freeze Bitcoin's capabilities but would also classify many existing financial tools from multisig to timelocks and covenants as invalid If applied as a fork, yes, but that's not what I want to do. I only want to apply it in my own mempool, by not speeding along transactions that I find stupid. Good point about multisigs and timelocks, though; if I ever get around to implementing my preferred filter I will try to ensure it allows those, as I do want to help relay such transactions around on the network. > The arbitrary exception for L2 HTLCs only proves the point: you're not defining spam, you're just green-lighting your preferred use cases Greenlighting use cases that I "prefer" -- as in, want to see more widely adopted -- is precisely what I want to do in my own mempool. I don't want to help people spam the network; I want to help them adopt layer 2s and sometimes use L1 as money. So I want a filter that supports the latter things -- the things I like and want in my mempool -- and locally blocks the other things -- the things I don't like and don't want in my mempool. > The arms race is asymmetric: This isn't a battle of diligence; it's a battle of economic incentives. There's a powerful financial motive to embed data, but only a weak, ideological one to filter it. I suppose a similar thing is true of email spam: the motive to get email spam in front of many eyeballs is more powerful than my motive to block it from my inbox. Nonetheless, email filters are powerful enough to largely compensate for that asymmetry, and I'd like to help design mempool filters that offer similar compensation. > You're underestimating steganography: You're focused on overt data, but the real challenge is data hidden within what looks like a perfectly valid financial transaction. A filter cannot distinguish intent. To block it, you'd have to block entire classes of legitimate transactions that are valid under today's consensus, which is a non-starter Filtering entire classes of transactions that are valid under today's consensus is what this entire debate is about. I am enthusiastically in favor of doing so in my local mempool, and sharing what works with others who may have similar interests.