"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.

Ah OK. It seems you want to discuss node centralization after discussing mining centralization. I want to discuss them together, for this reason: it seems to me that the principal argument against restoring the op_return limit is that some amount of increased miner centralization pressure is foreseeable if spammers relay their spam through private mempools instead, and this centralization pressure can be reduced by relaying spam through the public network instead. But I think the phrase "the cure is worse than the disease" applies here. Specifically, the amount of centralization pressure such activity is likely to produce is small by comparison with the even worse amount of node centralization that is foreseeable if spam is relayed by default in the most popular node software. Therefore I think the two forms of centralization pressure deserve to be compared with one another, and thus discussed together. To that end, you asked what is the purpose of properly assigning blame. It is in response to an argument against filters that seems popular to me: that they are bad because they force spammers to use private mempools. E.g. see this letter from a group of bitcoin core devs: "Knowingly refusing to relay [spam]...forces users into alternate communication channels." https://bitcoincore.org/en/2025/06/06/relay-statement/ This argument is false because it commits the false dichotomy fallacy, by asserting that a spammer discouraged from doing bad action A is thereby forced to do bad action B. Thus, the argument blames the discourager for doing a good thing (trying to stop bad action A) when the only one blameworthy is the spammer, since he is the only one who did anything bad. The fallacy is captured by a famous limmerick: There was a young man from Darjeeling Who got on a bus bound for Ealing It said at the door, "Don't spit on the floor" So he stood up and spat on the ceiling The position that Core's former anti-spam mempool policy forced some spammers to use private mempools, and thus the policy should be removed, is equivalent to arguing that the anti-spitting-on-the-floor policy forced the man in the limmerick to spit on the ceiling, and thus the anti-spitting-on-the-floor policy should be removed. On the contrary, if there is good evidence that the policy helps prevent spam that would otherwise harm the network through node centralization, then I think it should stay and continue doing that, unless the amount of mining centralization foreseeable is worse.

I am glad you are making an informed decision. :) Also, I recommend ceasing use of bip47. Silent Payments are imo a superior way to do what bip47 does. Also, I hope a new version of samourai's protocol becomes popular that fixes the part of tx0 that makes it incompatible with the default mempool policy in knots. If their protocol uses an op_return, it shouldn't imo.

I think spam is an important topic in bitcoin

Future me: you want to run a node? Great! There are 2 main kinds: Core and Knots. The main difference between them is how they approach spam. Core takes a welcoming stance toward spam transactions, whereas Knots filters them out as much as possible. Which one do you want to run?

I think you're trying to convey an argument or a question that I'm not properly receiving. You laid quite a bit of stress on segwit's blocksize increase and reasons for thinking I've concented to it. But I don't see how segwit or my consent to it is relevant, or what I might have said to make you bring it up in this context. Do you think it is important to understand your argument or question?

I agree that there is a centralizing effect when large miners mine spam, and I blame that centralizing effect on the people who create spam and the miners who mine it, rather than on the people who filter it. I also think relaying spam has a centralizing effect because it disincentivizes running a node, and I think the mempool policy adopted in Bitcoin Core is directly responsible for part of that centralizing effect. By contrast, Knots is not responsible for the centralizing effect produced by golks who bypass Knots's filters. Thus, both approaches involve a centralizing effect, and an important question is, which effect is worse? One is directly attributable to the mempool policy in Bitcoin Core, which welcomes and redistributed spam; the other is directly attributable to spammers and spam-miners who build tools to bypass Knots' filters. I think the former is worse than the latter.

> I believe it would take some ~95% of nodes to filter certain transactions before it meaningfully stifles their ability to make it to miners I agree, especially with your parenthetical caveat. However, I also think many miners start questioning the wisdom of mining widely filtered transactions well before ~95% filtering is reached. Mining a widely filtered transaction means your block will propagate more slowly than if you did not mine that transaction, which, especially for small miners, increases the likelihood of it becoming a stale block. Making miners think twice about whether it's worth it is, imo, a good thing. Again, the more people run filters, the stronger this effect, but I bet it starts having an effect as early as 50% filtering.

I didn't have a definition in mind, but I don't think Nakamoto consensus applies here. The more people run filters, the more I think there's a consensus that they are a good idea. So I guess by consensus in this context I mean "agreement by the people who opt to run the filtering software."

Yes, it is also important to avoid address reuse, and my example does not do that