Thanks, that is very helpful!

Has anyone made a website that displays a side-by-side live comparison of a default Knots mempool and a default Core mempool? It would be cool to have that so I can point to it as empirical evidence against the claims of those who shout that the filters make no difference

> it's also valid that having to re-download transactions that were already filtered out is an impact

Nodes don't just "download" transactions, they also "upload" them to their peers, again and again as long as they are in the mempool and they have peers to upload them to. Core folks love to focus on the fact that if you eject spam from your mempool and it gets into a block, you will redownload it. But they neglect that if you *keep* spam in your mempool, you will repeatedly upload it to your peers. So removing it actually saves you on bandwidth. You may have to download it twice, but you have to upload it 0 times instead of 7 or so.

> it's also valid that having to re-download transactions that were already filtered out is an impact

If you use Core v29 or v30, they bring new costs: the costs of helping relay and store spam, mostly for the sake of scams, and also to help various brc20 altcoins compete with bitcoin. These costs include up to $11.40 per year in bandwidth. Consider running Knots to save money. https://x.com/ProofOfCash/status/1982903129323778295

I agree completely

When my mempool does what I want, I do not consider it kneecapped, but well formed

And I want my mempool to eject most spam, because spam uses my system's resources for harm instead of for good

There is a reason to tolerate spam in the blockchain: ejecting it requires a large amount of hashrate, or switching to a different chain, and the cost is high

But the same reason does not apply to your mempool: ejecting most of it from there is easy, and the cost is low

There are reasons to tolerate spam in the blockchain: ejecting it requires a large amount of hashrate, and the cost is too high

But the same reason does not apply to the mempool: ejecting most of it is easy, and the cost is low

"The law meant to prevent drinking in the parks does not prevent drinking in the bars. Therefore, remove it!"

"The ordinance meant to prevent loud music in the library does not prevent loud music in the nightclub. Therefore, remove it!"

"The house rule meant to forbid shoes in your living room does not forbid shoes in your foyer. Therefore, remove it!"

"The filter meant to eject spam from your mempool does not eject spam from the blockchain. Therefore, remove it!"

"The policy meant to eject students from the staff lounge does not eject them from the school. Therefore, remove it!"

Same energy

"The filter designed to stop spam from entering your mempool does not stop spam from entering your blockchain. Therefore, remove it!"

"The door designed to stop students from entering the staff lounge does not stop them from entering their classrooms. Therefore, remove it!"

Same energy

Should be easy to defeat then

I welcome you to try

Because spam discourages users from running nodes

I used the analogy of a Justin Bieber forum to highlight this: users want their server software to do the things they had in mind when they started running it. If "storing NFTs for use in altcoin marketplaces" is not one of those things, and yet other people are in fact using their server software to do that, then that is a technical problem. If they see no way to remedy the situation, it may very well discourage them from continuing to run that server.

In the case of a Justin Bieber forum, I think its host *wants* to serve the text of posts about Justin Bieber *without* becoming a file storage system for NFTs. In the case of bitcoin, I think it varies more, but a large number of its node runners want to serve monetary transactions without becoming a file storage system for NFTs. If their server is filled with monetary transactions and very little spam, they will probably be delighted that their server software is working well and doing what they want. But the more spam there is on their server, they may become increasingly dissatisfied with the software, and stop running it. Just like a Justin Bieber server might just quit running the server if it gets filled with too much spam.

On a related note, some node runners seem more willing to tolerate storing and relaying spam if it bets mined into blocks, and I suspect part of the reason for that is because "undoing" the spam-inclusion would require expending lots of hashpower, and it doesn't seem worth it. But in *your own mempool,* you can exclude most spam from that pretty easily, and spam filters help you do so. They help solve a technical problem in an effective way. It is therefore no surprise that when Core announced its intention to remove the large-op-return filter, many users switched to software that keeps it.

If you want your coffee maker to stop coffee grains from entering your coffee, and it doesn't, that's a technical problem. Coffee filters help.

If you want your mempool policy to stop spam from entering your mempool, and it doesn't, that's a technical problem. Spam filters help.

No, I think 1MB of OP_RETURN data creates additional centralization pressure that 1MB of monetary transaction data does not

Yes

"But empirically less of it."

Sounds like you misunderstood my argument, which is not that *standard* transactions create additional centralization pressure on nodes, but that *spam* transactions do

I think it matters that some blocks are full of dickbutts. It matters in a similar manner to this: imagine you ran a popular forum for discussing Justin Bieber. But one day you visit your forum and see a bunch of posts containing jpeg dickbutts, and learn that instead of discussing Justin Bieber, a bunch of spammers decided to use your server as a file storage for their NFTs. It would be strange to say, "Well that's no concern of mine, if people want to use my server for dickbutts, great!"

If people use your server for something contrary to what you intend it for, it's a technical problem. I think there are a lot of bitcoiners who want their blockchain to store *standard* transactions, not dickbutts, and they want their mempool to *relay* standard transactions, not dickbutts. Filters effectively help. Specifically, they stop your mempool from relaying the most common formats used to share dickbutts on nodes, and when widely used, they also disincentivize at least small miners from mining dickbutts. That is a technical solution to a technical problem. Which is why I think filters are good and important.

> Silent payment is right now unusable for light mobile clients so not a solution tonreplace bip47, I don’t need a separate scanning server for SP, BIP47 is serverless

I don't think silent payments requiring anything more than bip47 does. How does your Bip47 wallet identify which blocks contain payments for it? If you look into it, I suspect you'll find it is by getting information about blocks from a server, which is how SP wallets do it too

> Op_return in Tx0...contains info allowing the server to verify that the fee was actually paid to a publisher

If the publisher tells their fee address to the server, the op_return is not needed. Neither solution requires a static fee address

>. It's an anti-spoofing mechanism. If the fee is not seen on chain then the inputs are not registered. It also allows to NOT use a static fee for address collection.